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UNIT -1: CONVENTIONAL SOFTWARE MANAGEMENT 


Evolution of software economics, Improving software 
economics — Reducing product size, software processes, 
team effectiveness, automation through software 


environments, Principles of modern software management 


UNIT- lI: SOFTWARE MANAGEMENT PROCESS 
FRAMEWORK 


Life-cycle phases — Inception, elaboration, construction and 


training phase 


Artifacts of the process - The artifact sets, management 


artifacts, engineering artifacts, pragmatics artifacts ............--- 


Model based software architectures, Workflows of the 


process, Checkpoints Of the process «----ereseeesreeeresssererseer 
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CONVENTIONAL SOFTWARE 
MANAGEMENT 


EVOLUTION OF SOFTWARE ECONOMICS, IMPROVING 
SOFTWARE ECONOMICS, REDUCING PRODUCT SIZE, 
SOFTWARE PROCESSES, TEAM EFFECTIVENESS, 
AUTOMATION THROUGH SOFTWARE ENVIRONMENTS, 
_ PRINCIPLES OF MODERN SOF 


Q.1. Write short note on conventional software management. 


Ans. The term CSM (conventional software management) practices are 
sound in theory, although practice is still tied to outdated technology and 
techniques. A performance benchmark for CSM principles is provided by 
conventional software economics. The flexibility is best thing about the 
software because it can be programmed to do anything. Also the worst thing 
about software is its flexibility because the “almost anything” characteristic 
has made it difficult to plan, monitor and control software development. 


The important analysis of the state of the software engineering industry 
are as follows — 


(i) An immature process is indicated by the level of software scrap 
and rework. 


(ii) Software development is still highly unpredictable, only few 


Percentage of software projects are delivered successfully within initial budget 
and schedule estimates. 


(iti) Management discipline is more of a discriminator in success or 


failure than are technology advances. 


Q.2. Explain the waterfall model. 
Ans, The 


areas, waterfall model or the classic life cycle is sometimes called the 
auen ) ggests a systematic approach to software 
‘gins at the system level and progresses through analysis, 


ting, and support. The principal stages of the model as 
are explained as follows — 


tial model. It s 
development that be iM 


esign, coding, tes 
Shown in fig. 1.1 


(R.GP.K, June 2011) — 
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(@ Requirements Analysis and Defin 


constraints and goals are established b: ition ~The Sian 
y consultation with ms 
System us, 


are then defined in detail and serve as a system specificati 
ication. 


Service, 
ers, They 


System and 
Software Design 


Implementation 
and Unit Testing 


Integration and 
System Testing 
E Operation and 


Fig. 1.1 Waterfall Model 


(ii) System and Software Design — The systems design process 
partitions the requirements to either hardware or software systems. It 
establishes an overall system architecture. Software design involves identifying 

“and describing the fundamental software system abstractions and their 


relationships. 

(iii) Implementation and Unit Testing — During 
software design is realized as a set of programs or program unit 
involves verifying that each unit meets its specifications. 

(iv) Integration and System Testing — The individual pene eke : 
or programs are integrated and tested as a complete system PE ur i 
software requirements have been met. After testing, the so arcs aes 
delivered to the customer. 


(v) Operation and Maintenan Nema 
eycle phase. The system is installed and WW ie 2 ia era i 

i ic! re no r 
involves correcting errors which were ewkê ei) 


life cycle, improving 
i ments ar ; 

system’s services as sivê 

( 3, What are the advantages and disadvantages of the > 

a wing advantages and disadvantages 

O? 


this stage the 
s. Unit testing 


units 


ce — Normally this is the longest i 
actical use- aintena! 


del? 
fall 


Ans. There are foll 
model — 


nt 5 
Conventional Software Manageme! 


Advantages — í 
(i) Relatively simple 
(ii) Each phase of development pr 
(iii) Allows managerial control whi 


set for each stage of development. 
(iv) Helps in controlling schedules, budget: 


to understand. 
oceed: 
ere a schedule with dea 


s sequentially. 
dlines is 


s and documentation. 


Disadvantages - 


(i) Requirements need to be specified before the development proceeds. 


er phases of the waterfall model 


in lat a 
ing phase, it 


(ii) Changes of requirements i ge 
application is ın the testin 


cannot be done. This implies that once an 


is difficult to incorporate changes. 

(iii) No user involvement and working version 0 
available when the software is developed. 

(iv) Does not involve risk management. 

(v) Assumes that the requirements e stable and are frozen across 


f the software is 


the project span. 
Q.4. Describe Boehm’s top ten list at put conventional software 


management performance. 


Ans. Boehm’s top ten list about conven.ional 
software mai 
performance are as follows — oe 
ev E Dê cae a softwar2 problem after delivery costs 
j re than finding and fixing the problem in earl i 
It is based on the proverb stitch in time saves nine. a 


(ii) We can compress sı 
percent Of nominal p oftware development schedules twenty five 


(iii) The cost of th 3 
e maintenance i -ٌ 

development cost. 3 ce is approximatel i 
than additi - Hence an incremental cost in develo lately twice the 
itional maintenance cost pment is more beneficial 


(iv) Primarily ; 

a function of 
softwa of the numb 5 
re development and maintenance costs. er of source lines of code are 


hardware cost, 


(vii) Only about fifteen pı 


devoted to 
; programmin; 
design and te sting, 8, and rest 


T¬ n 
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ically cost three times as 
e stems and products typically 
Û Say software programs. Software system products 
much per 


ean uch. a N 
cost nine an uae and review of design, code, catch sixty percent 
(ix) Wal 


of the ae Fighty percent of the contribution comes from twenty percent 
x) Ei 


of contributors. 

Explain the basic parameters of software Gonia - 
we a oftware can be abstracted into a function of five basic 
Ans. The sı 


follows - ae Laas 
War kê. EN i oS parameter of the end product, that is typically 
(i) Size (S) - 


Vi i i vari unction points 
ofthe various source instructions or various f p 

ified in terms 

quantifie 


ded to develop the required functionality. new eka 
ioe ii) Process (Pr) — This param ee z unication overhead. 
Û ae de adding activities lkerenanî ee of software 
and to avoiı 5 ‘ N ) Û 
3 - This param o STE 
(iii) Renora are experience with the computer scienc 
bak aê CI ù 
E mn domain issues of the project. Ls TÛ 
and the applıc: į ent (E) — This parameter is mas Pa ip automa 
Û») Ergon (ren soe develope 
techniques availa’ ee aie 
i ired to quality © 
ik 2 This parameter is require = 
ge Mi tability. 
e a performance, Saiya Sê alculated cost can 
containing its features, P the: ters and the © 
3 ips between the 
The relationships 


se parame’ 

Û = ity; 
BEVÊ ê Effort = P x Ex Q* s" vironment, Quay 
ostS 


1, En: 

te the Personnel, 

S and Pr are deno o 
Soe o calculate software een 


-ٌ dti : el 
Size and Process- have been develope relationship 9” of 
Many parametric aoe into this form. ma important 4S k 
1 of them can be generally ab my of scale is o! develop™ 
ee and size exhibits a disecono of scale of software 
effo 


; iseconom: 
software economics. The diseconomy eater than one. 


result of the process exponent being gt 


ent is“ 


: i e grapi ye! 
cesses as shown in fig: e ordinate Ga nent Tê? 

r co! 
oint and pe! 


components and pro sidered to be constant. 


ie ftware a like SLOC, per function p 
to so! 


by an organization. 


the so; 
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The three generations of software development are defined as follows - 


(i) Conventional - Between 1960s to 1970s generations are 
craftsmanship. Organizations employed custom tools, custom processes, and 
virtually all custom Components made in primitive lan 
performance was highly predictable in that cost, sı 
were almost always underachieved. 


guages. Project 
chedule and quality objectives 


(ii) Transition - Between 1980s to 1990s generations are software 
engineering. Organizations employed more-repeatable method and off-the-self 
tools and mostly custom components make in higher level languages. Some of 
the components were available as commercial products, including the Operating 
system, database management system, networking and graphical user interface. 

(iii) Modern Practices - Softwares produced after year 2000 can 
be considered as modern softwares. In these software 70% are off-the-shelf 
components while 30% of the components need to be custom built. With 
advances in software technology and integrated production environment, these 
components-based systems can be produced very rapidly. 


Improved Return on Investment 


Between 1960s to 1970 s 
(i) Functional Design 

(ii) Diseconomy of Scale 
(iii) Water Fall Model 


Between 1980s to 1990 s 
(i) Encapsulation-based 
(ii) Process Improvement 
(iii) Diseconomy of Scale 


Year 2000 and On 
(@ Return to Investment 
Gi) Component-based 

(iii) Iterative Development 


Corresponding Environment, Size and Process Technologies 
Conventional 


‘Transition Modern Practices 
Environments/Tools: Environments/Tools : Environments/Tools = 
Custom Off-the-shelf, Separate Off-the-shelf, Integrated 
ize = Size: ‘Size 
100% Custom 30% Component-based, 70% Component-based, 
20% Custom 30% Custom 
Process = z 
: 


Process = Process 
Repeatable Managed/measured 


Predictable 
Usual 


Predictably Bad 
ee 
over Seheda Ba On Budget and 


on Schedule 
: Fig. 1.2 Three Generations of Software Economics 
@.7. How can you improve the software economics ? 
Ans. The five basic parameters of the software 
are economies, These are as follows — 


cost model that improve 
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(i) Decreasing the size or complexity | | 
(ii) Improving the development process i J 
(iii) Using more skilled personnel and better teams 

(iv) Using better environments 

(v) Trading off or backing off on quality thresholds. 


These parameters are given in priority for most software domains. The 
list some of the technology developments, process improvement efforts and 
management approaches targeted at improving the economics of software 
development and integration as shown in fig. 1.3. 


(i) Higher Level Languages (C++, 
Java, ete.) 
(ii) Reuse of Commercial Components| 
(OS, DBMS, etc.) 
(iii) Object-oriented (Analysis, 
Design, Programming _ 
(i) Iterative Development and 
Process Maturity Models 
(ii) Architecture-first Development 
and Acquisition Reform 


Size 


Abstraction and Component 
Based Development Technologies| 


Process 


Methods and Techniques 


(i) Teamwork and 
Win-win Cultures 
(ii) Training and Personnel 
Skill Development 
T) Open Systems and 
Hardware Platform Performance 
(ii) Integrated Tools | 
(Visual Modeling, Compiler, Editor, etc.) 
i) Hardware Platform Performance 
(DeReNG aso Assessment 
Statistical Quality Control 


Personnel 
People Factors 


E 


Environment 
Automation Technologies and Tools| n> 


oe 


sai. 
Performance, Reliability, Accuracy 


i are 
Trends in Improving the Economics of Softw 


Fig. 1.3 Important 


Q.8. Explain the reducing software product size. 
ity and return on investmen' 


t is to make 2 


amount of human: 
ize to 

age size 

ed as the genera 


i dabil i 
Ans. To improve affor 1 ee 
product which gets ee PS po mm 
rce material. For re o Te ee 
generated A the component-based development j 7 sot 
software solu bject-oriented programming, autom: Za diyen sy en 
term. Reuse, object-or! languages are all focused o! n ton * 
higher level programming -specified source dioc. re Ee aie 
with fewer lines of hu behind improvement 1) highes He curl č se 
r Se and fourth generation yete 
e ll es. Tools, Visual modeling too! 
generators 


GUI builders) pen 
i eviti 
i windowing 
onents (like operating systems, 
commerical comp! 
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DBMS, etc.), and object oriented technologies (like UML, visual modeling 
tools, architecture frameworks). 


0.9. Write short note on software crisis. (R.GPV., Dec. 2006) 


Ans. The term software crisis refers to a set of problems encountered in 
the development of computer software during 1960s. Within this period the 
software industry unsuccessfully attempted to build larger and larger software 
systems by simply scaling up existing development techniques. As a result — 

(i) Schedule and cost estimates were often grossly inaccurate. 
(ii) Productivity of programmers could not keep up with demand. 
(iii) Poor quality software was produced. 

The term software crisis is also often used to encapsulate all the ills of the 
software and computing systems industry. 

In late 80s and early 90s, the individual software developed lacked mainly 
on the portability. The complexity involved in porting one application to different 
platforms and also the complexity involved in distribution to users were very 
high. These facts also delayed the projects in search of suitable tools and 
caused frustration among users to learn different methods. 

“z¬ ea re e crisis is characterized by an inability to 
^ are on time, on budget, and within requi 
delivered software Systems are — ` Sel ye ud 
(i) Completely unsatisfactory 
(ii) Too late 
(iii) Far over the budget 


(iv) Poorly suited for intended users of the system. 


the software) Duplication of efforts 


due mince 
evelopment eee to absent of automation in most of 


a 
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Q.11. Explain object-oriented design. (R.GPV, June 2012) i 


Ans. Object-oriented design (OOD) transforms the previously created 
analysis model (using object-oriented 
analysis) into a design model that serves 
as a blueprint for software construction. 

Unlike conventional software design 
methods, OOD results in a design having 
several different levels of modularity i.e., 

major system components are partitioned 
into subsystems (a system-level “module”) 
and data and their manipulating operations 
are encapsulated into objects (a modular 
form that is the building block of an OO 
system). Moreover, OOD must describe 
the specific data organization of attributes 
and the procedural detail of every single 
operation. 
Fig. 1.4 illustrates a design pyramid 
for object-oriented systems. It is having 


the following four layers — a 

i = ts each of the subsys! 
(i) The Subsystem Layer It represent s Te r 

that make software enable to achieve user requiremen! s 

technical infrastructure that supports user requirements. + 

ra 
(ii) The Class and Object Layer —\t represents the P Av 

that make the system enable to be created using gener 
specializations. This layer also represents each object. ii he cs 
e design - y 

(iii) The Message Layer — It a) establishe 


each object enable to communicate W1 pe r 

internal and external interfaces for the system nts the data struc 

- sibilities Layer — JU TOPS y each Obie j 

(iv) The Respon: ‘butes and operations Tor CÊ heed ull 
for all attribui s the specifie joh fo” 


Message 
Design 


Class and Object 
Design 


Subsystem 
Design 


Fig. 1.4 The Object-oriented 
Design Pyramid 


jes 


represents thi 
th its collab 


and algorithmic design í r 
e OO design pyramid exolnsivey een : Wi Û 
i that another £ A ni 
e ba Ja De Ea rests. This basic Jaye a e je Wi. 
iC} e a 
E e objects, which play a a Du nee 
Û providing SUPP 
for the OO system by eae F n a 


activities, task management, an 
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A brief overview of the most important early OOD methods is as follows — 


(i) The Booch Method — This method encompasses both a micro 
development process and a macro development process. The latter encompasses 
an architectural planning activity clustering similar objects in separate 
architectural partitions, layering objects by abstraction level, identifying 
associated scenarios, creating a design prototype and validating it by applying 
it to usage scenarios. On the other hand, the former one i.e., micro development 
process defines a set of specific rules, governing the use of operations and 
attributes and the domain-specific norms for memory management, e 
handling and other infrastructure functions. It develops scenarios Wr dinê 
the semantics of the rules and norms. Also, it creates a prototype for A 
fb instruments and refines the prototype and reviews each Bete so ie = 

roadcast the architectural vision of each norm by itself. 


(ii) The Rumbaugh Method - The OOD encompasses a design 


activity that promotes design to bı i 
Shela ton Cae ign e conducted at the following two different 


oer een Design - It concentrates on the frame for the 
aaa required for constructing a complete product or system 
k 1s categorized into diffe 1 

Stare afferent subsystems, that 
Processors and tasks. The data management strategy is gr 


and global resi 
ae ources and 5 
identified. control mechanisms, for accessing them, are 


- (b) Obj ê 
) Object Design - It focuses the detailed layout ofeach single 


object. The anal: 

lysis model i A 

defined. A; Provides operations and Z 

|. Appro; and for them ithms 

are egal eee se vetss are represented. Classes eae 

computational effici ay that optimizes access tı R 

+ ici É o data 

object relationships tency. A messaging model is designed to ae i 
H ni le 


es (iii) 
Or object-ori 
of the propri are engineerin, 
kawan g (OOSE), w : : 
7 K OOSE A bjectory method”. This Û o (e Dd version 
at the i 
“blocks” nvironment, After that 
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its infrastructure and concentrates on the Te} 
major system components — 


‘Presentation of following four 


(a) The problem domain component 

(b) The human interaction component 
(c) The task management component 
(d) The data management component. 


a (vy) The Wirfs-Brock Method - In this method, a continuum of 
technical tasks are defined in which analysis leads seamlessly into design 
Protocols for each class are constructed by refining the contracts baren 
objects. Each protocol and operation is designed in detail, so as to make 
implementation easy. Specifications for each class and each subsystem are 
developed. 


Q.12. Write the benefits of object-oriented design. 


Ans. There are following benefits of object-oriented design — 
(i) The concept of objects performing services is a more natural 
way of thinking. 
Gi) Objects are inherently reusable. 


Gii) Emphasis is on understanding the problem domain. 


Gv) Internal consistency of systems is improved because attributes 


and services can be viewed as an intrinsic whole. 

(v) The characteristic of inheritance capitalizes on the“ 
of attributes and services. 

(vi) The characteristi 
localizing changes to objects. 

(vii) The object-oriented develop: 
pies U Seyê za ae tem analysis approach fe 


is it different from traditional sys! ) 2 
0.13. How is it ails es ibe in performing object oriented analysis 


Describe the three majo. ka 
Ans. Difference between jeaditana dêzê ne ê 
OOA differs the most from structured analysis. a ee 

-oriented view of system providing a de bas? Bs 
ee whereas OOA decomposes the problem 
Lec canon entities. : 
Activities of Object Oriented Ana 
are identifying objects, identifying structures, 
associations, defining services. 


‘commonalty 


c of information hiding stabilizes systems by 


ment process is consistent from 


ê in the analysis 
— The major steps !! identifying 


identifying attributes, 
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Identifying Objects - An object during analysis is an encapsulation of 
attributes on which it provides some exclusive services. It represents something 


in the problem space. 

To identify analysis objects, begin by looking at the problem space and 
its description. Find a brief summary of the problem space. In the summary 
and other descriptions of the problem space, consider the nouns. Frequently, 
nouns represent entities in the problem space which will get modeled as 


objects. 

Identifying Structures — Structures represent the hierarchies that exist 
between object classes. In object modeling, the hierarchies are defined between 
classes that capture generalization-specialization and whole-part relationships. 
In generalization-specialization, the class being refined is known as the 
superclass and the specialized class is known as the subclass. 

The attributes and services of the superclass are inherited by the subclasses. 
The subclasses can add more attributes and services to specialize. 

To identify the classification structure, consider the objects that have 
been identified as a generalization and see if there are objects in the problem 
space that can be considered as specializations of this. The specialization should 
be meaningful for the problem domain. Similarly, consider objects as 
specializations and see if there are other objects that have similar attributes. If 
so, see if a generalized class can be identified of which there are specializations. 
Once again, the structure obtained must naturally reflect the hierarchy in the 
problem domain. It should not be extracted because some objects have some 
attributes with same name. 

i To identify assembly structure, a similar approach is taken consider each 
object as an assembly and identify its parts or components. See, if the system 
Fequites to keep track of the parts. If it does, then the parts must be reflected 
as objects. If not, then the parts should not be modeled as separate objects. 
Then consider each objectas a part and see to which object it can be considered 
as belonging. Once again, this separation is maintained only if the system 
requires it. As before, the structures identified should reflect the hierarchy in 
the problem domain and should not be forced. 


eee Attributes _ Attributes are the repositories of data for the 

Le A ey add detail about the object. For instance, for a person object 

ê We a could be the name, sex, and address. The data stored in 

enê values of attributes are hidden from outside the objects and are 
ssed and manipulated only by the service functions for that object. 


is a identify attributes, consider each object and see which attributes for 
ject are required by the problem domain. Then position each attribute 
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hat are to be manipulated by the program. Thus, 


shows much promise i 


software systems. 
(iv) Reuse-based Design Methods — Reuse-based design accepts an 


n of reusable modules, functions or designs, but crafts an 
ther in order to provide the specified software 


ofthe problem, function. For a module to be reusable, however, we must require that it should 


the overall transformation function for the system is partitioned into several be used by several other modules as in design-reusable structure. sh i 

smaller functions comprising the system function. The system decomposition fig, 1.5. It is, of course. not necessary to create a program top a ioe 
sm 0 | 1.5. Itis, rse, not -down, even 
is in terms of functional modules. though its structure 1s function-oriented. However, if we want to agi the 


Whereas in the object-oriented desi ty in the real world decision of what the system is supposed to do as long as possible, a better 
provides some services to the environment to which it belongs. This view is choice is to structure the program z 


supported by data abstraction. Data is treated not as an object simply, but as around the data rather than around the 
ts with some predefined operations on them. The predefined operations actions taken by the program. The unix 


ou: Discuss the differences between object-oriented design and 
function-oriented design strategies. 


properly using the structures. If the attribute is a TA hon "tribute, it should 
be placed in the superclass, whereas if it is specific tolh s A zed peo put instead on the data t : Ê : g $ 
should be placed with the subclass. Ñ j object it object-oriented design is orthogonal to function-oriented design. Object-oriented | 
technology is one of the latest approaches to software development, and it | 
n solving the problems associated with building modern i 
| 
u 


‘Ans. There are two common design strategies for software systems - 
d and object-oriented. In function-oriented, a module is existing partitio 


function-oriente 
ovides a basis for interface that ties them toge 


specified by its function. Function-oriented design pr 
partitioning in function-oriented approaches i.e., with partitioning 


gn strategy any enti 


objec 
on data objects are the only operations performed on those objects. Thus, the filter provides a good example of 
basis for object-oriented design is data abstraction. | reuse-based design by means of 
| toolki j a 
0.15. What are the various software design methods p | oolkit. Fig. 1.5 Design-reusable Structure 
RGE KE zû | Q.16. What do you mean by software reuse ? 


ude — | Ans. By software reu: 
se, we mean the re; d 
ê 2 SÎ system - dı ze E peated use of any part of: 
Function-oriented design is the | are vider ee Corle CNEA avrû ments ee os a software 
ne of the best ges E sel encourages us to think of maintenance as cae ee 
‘S| Te! 

f Pascal and ystem and reuse parts of it to build the next Ser he 

3 arly, he 


suggests that 
nement. 3 à processes and i 
| int experienc 
angible product of deer e can be reused, as can any tangible or 


Ans. The major software design methods incl 


n-oriented Design — 
function of the program. (0; 


s Niklaus Wirth, the creator © 
s called stepwise refi 


@ F unctio 
result of focusing attention to the 
known advocates of this method i 


number of other languages- His special variety i: A 
jon Methods - The best-known g 
ii) Data Structure based Desig” s yi sa 
,tru« AYÊ design methods werê developed in the mid 1970's 8? | T wê apos 
hes : > there are two ki 2 
these are — k | Teuser, Producer oe © kinds of reuse, as denned ai 
tae en Sê Uses them in subse se creates reusable components y the perspective of 
x 
` Xa Ti a ing the Whole, without E systems, As consumers. and consumer reuse 
t (JSD) using | particul ification (called |, We Gem ci tü cr e alprod 
Bane oe sae es BLE aan is a struc r When We needs (called clear-b, ed block-box reuse), or modify it tı La luct 
3 -ٍ ing (JSP). is by e use rı -box reuse a iis aaa 
Û ee uv moere Een î introd ced î 01 Outines fro; ). We perform bl: 
Tans nd desi 715). TOE KÊ introt oW | m predefi m mathemati lack-box reuse oft 
. anit ee i js kno" Olah ets cal librarie: î en, 
tse e „aa S ] nique proposed Py adê Ê su 2bility to veri of components. An im; sor build graphical interfaces 
sa a cone er ee ceptable wa: ify that a Teused modul: portant issue in black-box reu 
Dur pani iented gest | û If it is a thse ê e component is ees its required function a 
5 — Object-orl! earn see ai i 
oe Mahor the prog” | Which it is îns lê Want to be sure it her) di to be sure it is failure- 
; ly exercises the functi 
tion 


(iii) Object-oriente eê 


sult of focusing attention not on the function per 


the re: 
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Clear-box 
reuse (sometiı 
but still contr i mes called White-box i 
oversial, because the effort to un reuse) is more common 


component must be less than the effort to bee understand and modify the 


© address this roblem, many reusable co; nponen ee be a DUI can 
8 
I p! any 


parameters, makin; i ; š 
eee > : g them easier to tailor with an external view, rather 
g developers to understand the internals. eget: than 


Q.18. Discuss the advantages and disadvantages of reused code i 
software development. (R.GP.V., June 2005, 2008) 


Ans. Advantages of Reused Code — 


f (i) Increased Reliability — Reused components that have been 
exercised in working systems should be more reliable than new components, 
They have been tried and tested in a variety of different environments. Design 
and implementation faults are discovered and eliminated in the initial use of the 
components, thus reducing the number of failures when the component is 


reused. 
s Risk — If a component exists, there is less 
uncertainty in the costs of reusing that component than in the costs of 


i i n j é it reduces 
is is an important factor for project management as ! 
na ze - s is particularly true when 


the uncertainties in project cost estimation. Thi X 
relatively large components like sub-systems are reused. A 
i Cı 
(iii) Standards Compliance- Some standards, such as user inter! 
ii 


standards. can be 1 i ented as a set of standard com| nents. For example, 
„ can mplem« r pi c ip) 
E bi e. 
T eusable components maybe developed to implement menus in a user terfa 
s are less A ly to make mistakes 
All appli tions ù 


s reliability as user: 


(ii) Reduced Proces: 


er interface improve! jabili - A 
E esented with a familiar interfac çaha i 
e Use of. Specialists _ Jnstead of app e = 
age j special 
(iv) e on different projects, T 
det ÛÛ aeni which encapsulate the! 3 Ê e 
usable e ; : 
re w) Accelerated Developmen a av i a 
i ore importan senin 
a eee s system production 
s 
TA fee should be reduced i 2 
; 
vi > es of Reused Co F . To 
pisadvantag jen - 
ased Maintenan fi f porensed A 
(i) mere coss be e 
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(ii) Maintaining a Component Library — Populating a component 
ng that software developers can use this library can be 


library and ensuri a 
rent techniques for classifying, cataloguing and retrieving 


expensive. Our curl | 
software components are immature. 

(iii) Lack of Tool Support - CASE toolsets do not support 
development with reuse. It may be difficult or impossible to integrate these 
tools with a component library system. The software process assumed by 
these tools may not take reuse into account. 


(iv) Finding and Adapting Reusable Components — Software 
components have to be discovered in a library, understood and sometimes 
adapted to work in a new environment. Engineers must be reasonably confident 
of finding a component in the library before they will routinely include a 
component search as part of their normal development process. 


6) Non-invented-here Syndrome — Some software engineers 
sometimes prefer to rewrite components as they believe that they can improve 
on the reusable components. This is partly to do with trust and partly to do 
with the fact that writing original software is seen as more challenging than 
reusing other people’s software. E 


Q.19. Write short note on commercial component. 


gare A common method being pursued today in several domains is to 
STÊ a integration of commercial components and off-the-shelf products. 
aer ee i of pe components is certainly desirable as a means of 
stom de i z :ٍ 
ation velopment, it has not proven to be straightforward in 


The i 
advantages of commercial components are as follows — 


ê (i) Its co i 
independence. mmercial components allow hardware and software 


(ii) 
ii) 
(iv) 


It - 
: ; components allow predictable license costs. 
t is used mature technology. 
Com i 
WAN mercial components are easily available. 
^ A are dedicated support organization. 
ithe lata functionality of these components are rich. 
ORS HA of Commercial components are as follows — 
Û urrin; i 
(i) Maintenance fees and up-front license fees. 


Commerci 
Gi) u. ul components are depend on vendor. 
ntegration not always trivial 
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iv ”s run-ti i 
(iv) It’s run: ‘time e ficiency Sacrifice: 
S. 


(v) It’s unne 
cessal 
(vi) S 3 ry features that consume 
ome disadvantages of cone extra resources 
s a ` 


upgrad 5 - é 
pgrades, functionality constraints, multiple-y ical components are frequent 


endor ine ibili 
ğo ‘ompatibility, 
t do you mean by a software Process ? (R.GP V. ` 
az KA software process is a set of activitie: ae 
among them, such that if the activities are performed properl 
perly and 


in accordance with the orderi i 
‘ | ring constraints, the desi i 
The desired result is the high-quality software at wane ey a 


2015) 
S, together with ordering 


Q.21. What are the activities of software process ? 


of Ans. i 
he. s. There are four fundamental process activities which are common 
o all software processes. These activities are — 


’ (i) Software Specification — The functionality of the software and 
constraints on its operation must be defined. 
(ii) Software Development — The software to meet the specification 
must be produced. 
(iii) Software Validation — The software must be validated to ensure 
that it does what the customer wants. 
Á (iv) Software Evolution — The software must evolve to meet 
changing customer needs. 


h elas d Q.22. Describe the important characteristics of a software process. 
rn (R.GP.V., Dec. 2004) 
(o roguire ' 
A men Ans. The main obj ective of process is same as that of software Cnr ee 
calability. Optimality defines the process shoul ne 
S 


imality and sı ce 
e anê K ost, while scalability mean 


Ein derde 

mar high-quality software at low © 

j able to produce high-q h a 
wd it should also be applicable for large software projects. So, Pos sare 
ynaracteristics to achieve the objective, W ic! 3 


have some desirable c 
follows — 
(i) Predictabili 


damental property of any process. l 
A accurately the outcome of following process ! 


before the project is completed. If a process is no 


limited use. 

Similarly, quality pes 
largely by the process use 
of a project can be estimated or 


field, 
pe 
Û 


ty = Predictability can be ¢ 
ess. Predictability of a pro 
n a project can 


t predictable, t 


iction i i the prod! 
tion is that quality of th 
Oo it, On this basis, quay 
predicted by seeing the quality 
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ng used in the cul 
ctivity largely dep 


Convention: 

i rrent 
S 1 

t by the process be: pr 


d in the pas! 
ne f quality assurance a 


ment o: 


1 also called as under statistical 
a process, which are 
are only probabilistic. 


on the predictabili 
A predictable process 1s und 


Statistical control implie 
don the past performance of the process, 


ho wants to consistently develop software of high quality at 
sary to have a process that is under statistical control. A 
s an essential requirement for ensuring good quality and 


control. 
generally base 

So, if one wl 
low cost, it is neces: 
predictable process 1 
low cost. 

(ii) Testability and Ma 
of the development project sho 
maintain and the process should be suc 

3 The second important effort is the testing, which consumes most resources 
during development. Underestimating the testing effort often causes the planners 
to allocate insufficient resources for testing, which in term, results in unreliable 
software or schedule slippage. 

ge goal of the process should not be to reduce the effort of design and 

= ae but to reduce the cost of testing and maintenance. Both testing and 

en ae ee nee on the design and coding of software and these 
considerably reduced if the software is desi i 

$ 4 si; 
make testing and maintenance easier. gned and coding to 


intainability — One of the important objectives 
uld be to produce software that is easy to 
h that it ensures this maintainability. 


the main 
during th 
reality, sometimes testing is the sole 


reliance on testin 
Hag e 
the limitations of testing, .. 


and correction should be 
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e engineering is chosen b 
ased on the na 
the methods and tools to be used, Tn 
> e 


All softw: 
c pas ae be characterized as a problem solving | 
= 1.6) ich four distinct stages are ae 
j problem definition, technical E e Cd arian We ae 
ete : S ation. Statu: 
p ts the current state of affairs; problem definition identifies the eren 


problem to be solved; technical 
development solves the problem Bdn 
Definition 
Technical 
Development 
Solution 
Integration 


through the application of some 
technology and solution integration 

Fig. 1.6 The Phases of a Problem 

Solving Loop 


delivers the results (e.g. 
documents, data, programs, new 
product, new business function) to 
those who requested the solution 
in the first place. 

This problem solving loop applies to software engineering work at many 
different levels of resolution. It can be used at the macro level when the entire 
application is considered, at a mid-level when program components are wae 
engineered and even at the line of code level. Hence, a fractal as 
can be used to provide an idealized view of process. Tt is important to n a 
that each of the models has been characterized in a way that ass! 

control and coordination of a real software project. Sedê 

9.23. What is software process ? Define the e ees 5 ıl) 

projects and product. 


Ans. rocess — fer to Q.20. 

„ Software P. Re 
roce: ecifies a method of developing softwa! 

A software proc ss, SP! Û 
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activities are being executed are Software Processes 


the products. The software ee 


be viewed as an Projecty Project Project; *** Projectn 


process can Ê ; 
abstract type and each project is A oes 


done using that process as an 


instance of this type. In other Product; Product} *** Product, 


words, there can be many Fig, 1.7 Processes, Projects and Products 
projects for a process and there : i i ; ~n f 
can be many products produced in a project. This re lationship is shown In 
fig, 1.7. ; ; 
Now a question arises, if the sequence of activities is provided by the 
process, what is the difficulty in following it in a project 9 First, the sequence 
of activities specified by the process is typically at an abstract level because 
they have to be usable for a wide range of projects. Hence, “implementing” 
them in a project is not straight-forward. In a sense, the process provides a 
“checklist”, with an ordering constraint. 
Overall, the process specifies activities at an abstract level that are not 
project-specific. Itis a generic set of activities that does not provide a detailed 
road map for a particular project. The detailed road map for a particular 
project is the project plan that specifies what specific activities to perform 
for this particular project, when and how to ensure that the project progresses 
smoothly. 


eo It should be clear that it is the process that drives a project. A process 
limits the degrees of freedom for a project by specifying what types of activities 
ae be done and in what order: Further, restrictions on the degrees of freedom 
for z particular project are specified by the project plan, which, in itself, is 
n Be, boundaries established by the process. With this, the hope is that 
ıe has the “shortest” path from the use! ds ti isfyi 
heen pi user needs to the software satisfying 
ae hs each project is an instance of the process it follows, it is essentially 
T pi that determines the expected outcomes of a project. Due to this, 
us of software engineering is heavily on the process. 


0.24. Explain and differentiate between the software process and product. 
= (R.GP.V., Dec. 2004, 2009) 
Write di 2 
rite difference hetween process and product. 
(R.GP.K, June 2005, 2015) 


Following : i 
g are the dif ae 
mune fferences between a software product and a 


Ans, 
Software 


Azê, 
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D 


> 
Soft po TY) Ewn 


Software process is the series of 
steps which must be followed to 
develop a timely and high quality 
software product. 


Software Product 


Software product is the resultant 
computer software that software 
engineers design. 

(ii) | It includes programs which can 
run on any computer, documents 
in the form of hard copy and virtual 
forms and relevant data and pictures. 


It defines a framework for a set of 
key process areas (KPAs) that 
must be established for effective 
delivery of software engineering 
technology. 


It is the main driving force that 
drives business decision making. 
It serves as the basis for modern 
scientific investigation and engin- 
eering problem solving. 


It provides stability, control and 
organization to an activity that can 
if left uncontrolled, become quite 
chaotic. 


It is built by applying software 
engineering approach, by applying 
a process that leads to a high 
quality software. 


for the creation of website. 


Software product depends on 
software process for its stability 
quality and control. 


wss of 


product. 


9.25. Define SSPI and explain the failure analysis used by SSPI. 


Or 
ovement. (R.GP. V, Dı 


Explain statistical software process imp! 


x Statistical software p! -ٌ MO ea Mê short 

E btained by +he derivation of simple indicato! ane 
approach obtal à t information about à a 
software a system or product is develope 
encountered as 


ê ws — ks 
es far pene defects are classified by origin. 
1 


dee Sais Ê in each class is countel al 
J 
rs and defects 
number of erro 


rocess improve 


(iv) The total co: 


of the organizal 


the 


Software Interface 


0% 
Hardware Interface} 
1.1% 


Selecting a process depends upon 
the software you’re buildingas one 
process might be appropriate for 
creating software for aircraft 
avionics system while an entirely 
different process would be required 


It is more important than software 


ec. 2005) | 


ment (SSPD) is a rigorous 
S 


and defects 


quality factor 

unde: Û ed apa s ` 
total. Bach of r consideration i.e., specific defects accounting 25% of the 
Potential 
Specificay 


and defect js noted. wê 


tibs notati 


ftware Management 2 


Conventional So! 
g highest cost 


Jass havin: 
lyzed to get the € 
tant data are ana 
(v) Resu: 


ed i eS, 
Ne thods are discovered to modify the proc 
A and defects which are most costly. 


which eliminates 


(vi) 
class of errors 


Logic 20% 


Data Handling 


10.5% Origin of Errors/Defects 
Specification/ 
Standards Requirements 


6.9% 


Error Checking 


10.9% Specifications 
„9% 


25.5% 


User Interface 
11.7% 


Fig. 1.8 Causes of Defects and th 


eir Origin for Four Software Projects 


Missing Ambiguous 


Specification 
Defects 
Wrong Customer Queried 
Customer gave 
Wrong Info. 
Inadequate Inquiries 
Used Outdated 


info. 
Incorrect Changes 


ê. Fig. 1.9 A Fishbone Diagram 
Fig. 1.8 illustrates a simple defect distribution for four software projects, 


whi i 
ich can be developed by following steps (i) and (ii), noted above. For the 


Pic-chart noted i À b . E 
shown, “Gra ayn the fig. 1.8, eight causes of defects and their origins are 


in fig. 1.9 


=~ AShEBeSta that the development of “fishbone diagram” (shown 
Dine a pu diagnosing the data represented in the frequency diagram. 
g- 1.9, the spine of the diagram i.e., central line represents the 


the four ribs i.e., di g 
.e., dia; 5 £ 
causes for the onal lines connecting to the spine 


tions, incorrec 
lon are then a 


e l onr represent 
quality problem i.e., missing requirements, ambiguous 


t requirements, changed requirements. The spine and 


ppended to-each of the major ribs to expand upon the 


kalma nazanê 1ı. 
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cause noted (here, expansion is shown only for the in \ 
collection of process metrics is the driver for the n A 
diagram. A completed fishbone diagram can be analyzed ane, idi 

that will enable a software organization to modify its proce: 5 rû HA 
frequency of errors and defects. ê pîrê yayên ihe 


Q.26. How to make any software ive ? 
process effective ? 
the effectiveness ? Tg Howes menue 
Or 
Explain process metrics and software process improvement, 
(R.GP.V., June 2005) 


Ans. There is only one rational way to improve any software process i.e. 
to measure specific process attributes, develop a collection of meaningful TESE 
based on those attributes, and then use it to obtain indicators leading to a strategy 
for improvement. It is important to note that process is only one of a number of 
controllable factors in improving software quality and system performance. 


Observe the fig. 1.10, process sits at the centre of a triangle connecting 
three factors influencing the software quality and organizational performance. 
The skill and motivation of people has Product 
been shown to be the single most 
influential factor in quality and Customer 
performance. While the product “gests 
complexity also has a substantial impact UNUSED 
on quality and team performance. And 
on the third end, technology that 
populates the process also has an Development 
impact. The process triangle exists Environment 
wade? a grde of environmental Fig. 1.10 Determinants for Software 
conditions including the development Quality and Organizational 

environment, business conditions, and Effectiveness 

customer characteristics. A 
Now the effectiveness of a software process can be measured indirectly 
ie. we derive a set of metrics on the basis of the results derived for the 
process, including measures of errors uncovered before software release, 
defects provided to and encountered by the customers, work products delivered 
ie., productivity, human effort spent, calendar time spent, schedule confor- 
mance and several other measures. Also, process metrics are derived by 

measuring the characteristics of particular software engineering tasks. 


Business 
Conditions 


People Technology 


9.27. How can improving software processes ? Explain. 


f Ans. For software-oriented organizations, there are many processes and 
sulgprocesses. Some of them are discussed below — 
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First process is metaprocess. This is an organization’s policies, procedures. 
ia practices for pursuing a software-intensive line of business. The main 


focus of this process is on long term strategies, organizational economics 
and a software return on investment (ROT). 


The metaprocess attributes are as follows — 

(i) Subject — It used line of business. 

(ii) Objectives - The objectives of this process are competitiveness 
and line-of-business profitability. 

(iii) Audience - In this process audience are organizational 
management and acquisition authorities. 

(iv) Metrics — Market share and project predictability revenue are 
metrics of this process. 

(v) Concerns — This process allows standardization vs bureaucracy. 

(vi) Time Scales — The time period of this process is 6 months to 
one year. 

Second is macroprocess. This is a project’s policies, procedures and 
practices for producing a complete software product within certain cost, 
schedule and quality constraints. The main focus of this process is on creating 
an adequate instance of the metaprocess for a specific set of constraints. 

The macroprocess attributes are as follows — 

(i) Subject — This process is used in project. 
(ii) Objectives — The objectives of this process are risk management, 
quality, schedule, project budget and project profitability. 
(iii) Audience — In this process audience are software engineers, 
SPM (software project managers). 
(iv) Metrics — Major milestone success, on budget, project scrap, 
Tework and on schedule are metrics of this process. 
ce ©) Concerns - This process allows financial performance vs 
quality <= 
(vi) Time Scales — The time period of this process is one year to 
many years. 
oe is microprocess. This is a project team’s policies, procedures and 
ib ices for obtaining an artifact of the software process. The main focus of 
aie is on obtaining an intermediate product baseline with adequate 
and adequate functionality as economically and rapidly as practical. 
e mi 2 
microprocess attributes are as follows - 
@ Subject - This process is used in iteration. 
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(ii) Objectives- The obj 


Ti (iv) Metrics —Major milestone 
rework, on schedule and on budget are 1 


six months. 


business administration an 
added efforts, but in general, 


process improveme 
activities and minimi: 


personnel, computers and schedule. 


Ans. The most impo! 
balance. A team is vulnerab! 
cricket team has a nee 
team to use a sports analo 

didn’t have great coverage 
and personnel, good bow. g] 
team need coverage across key positi 
team loaded with superstars, all striving to S! 
to be the team leader, can be embi 
with a few leaders focused on th 
Sum of the individuals is not imp 
ager requires to configure a balanc 


det ectives of thi 
management, quality, schedule and Sue 


(iii) Audience ê 
— In this pr ‘ 
and subproject managers. process audie 


Process are risk reso! 


are 
e software engine 


Tı Sa ; 
poen release/iteration scrap and 
ue metrics of this process û 
7 ae b 

ncerns — This process allows schedule vs content. 


vi s X 
(vi) Time Scales — The time periods of this process is one month t 
0 


Most software projects need an incredibly complex web of sequential 
and parallel steps to get success. More overhead steps must be included j 
to manage the complexity of this web as the scale of a project increases 
Productive activities and overhead activities are the consist of project Ra 
Productive activities result in tangible progress toward the end product. These 
activities have prototyping, modeling, coding, debugging and user documentation 
for software efforts. Overhead activities that have an intangible impact on the 

end product are needed in plan preparation, documen 
risk assessment, financial assessment configuration control, quality assessment, 
integration, testing, late scrap and rework, management, 


d other tasks. Overhead activities have many V‘ 
ese activities, the 


The objective of 
es to productive 
sources such a 


tation, progress monitoring, 


personnel training, 


the less effort devoted to th 


more effort that can be expended in productive activities. 
nt is to maximize the allocation of resourci 


ze the impact of overhead acti 


Q.28. Define the term team effectiveness. 
tant factors of excellent 
Je whenever it i 


teams are coverage 


d for diverse skills, very much like 
gy. There has rarely been a 
— offense, defense a! 


i ower, 
Jer, batting r et anid 
et particu 
arrassed b 
e team result of w 
ortant than tl 
e of solid talent W! maxims 0 ti 


ople in the Jeverage positions with software teams. 
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management include the following — 

(i) A suitable-managed project can succeed with a nominal 
engineering team. 

(ii) A mismanaged project will almost never succeed, even with an 
experts team of engineers. 

(iii) A well-architected system can be made by a nominal team of 
software builders. 

(iv) A poorly architected system will flounder even with an expert 


team of builders. 
9.29. Write short note on software maintenance.(R.GP.V., June 2011) 


Ans, Software maintenance is the process of enhancing the functionality 
of the software or optimizing it for its performance or correcting newly 
encountered defects after delivery. Maintaining and enhancing software to 
cope with newly discovered problems or new requirement can take far more 
time than the initial development of the software. It may require addition of a 
new code that does not fit the original design. 

The maintenance may be defined by four activities. These four different 
maintenance activities are corrective maintenance, adaptive maintenance, 
perfective maintenance or enhancement, and preventive maintenance or 
reengineering. Only about 20% of all maintenance work is spent “fixing 
mistakes”. The remaining 80% is spent adapting existing systems to changes 

in their external environment, making enhancements requested by users, and 
reengineering an application for future use. When maintenance is considered 
ie all of these activities, it is relatively easy to see why it absorbs so much: 
effort. 


ER 0.30. What do you understand by software. project management ? How 
is it different from other types of engineering managements ? 

(R.GP.K, June 2010) 
that a es oal of project management is to ensure that a software product 
Gn ae quality specifications of the requirements definition is produced 
reece ule and at an economically justifiable cost within the planned 

S. 
a es words, project management is a series of activities embodied in 
Project a getting things done on a project by work with members of the 
Cost, Sake am with other people in order to reach the project schedule, 
Sı technical performance objectives. 
ikea fi managers do the same kind of job as other engineering project 
engineerin lowever, software engineering is distinct from other types of 
g in a number of ways that can make the software management 
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9.32. What is software supportability ? 


software engineering, supportability is one of the important aspect. 
It refers to the ability of technical support personnel to install, configure 
monitor computer products, identify exceptions or faults, debug or ipeiate 
faults to root cause analysis and provide software maintenance in pursuit of 
solving a problem and to restore products into service. Incorporating 
supportability facilitating features, reduces operational cost and maintain 
business continuity and mostly result in more efficient product maintenance. 


Ans. In 


Features of Software Supportability — 


Be (iii) Large Softw i 
me are Pı . . a 
nee aystemopthabarerdi ferent Ror rojects are Often One-off” Projects — New (i) Exceptional events help desk notification. 
E 2 Ae My be oS ol previous projects are common. There does (ii) Monitoring the network. 

WEKÊ Mac in Bolan: ly of previous experience that can be used to reduce (iii) Documentation 
HE Û iv) Software trackin; 

~ Q.31. Describe t i u a 

he components of software maintenance process. Why (v) Logging of program state like - 


cost of software maintenance is high ? 
igi (a) Local and global variables and execution path 


Ans. In software maintenance process followings are most important - (b) Procedure entry and exit 
(i) People, who are involved (c) Exception block entry 
(ii) Knowledge (semantics, structural) about the software product (vi) Software upgrade 
(ii) Supporting tasks, which are well defined. | (vii) Graceful degradation 
These three are inter-related and interdependent to each other as shown | (urd ware Ap Edo) 


0.33. Briefly describe software project management standards. 


in fig. 1.11. 
Components of Software | 
Maintenance Process | 2 (R.GP.V., June 2012) 
Explaii > r 
| ‘plain the term project management standards. (R.GP.V., June 2014) 
Or 


Explaii je 
‘plain software project management standards. (R.GP.K, June 2016) 


Ans. Softw. j 
„ Software project m: tan i 
requirements the following reasons 3 anagement standards are important because of 


Supporting 
Tasks 


Maintenance 
analysis 
Determination 


Required 
knowledge 


Operational 
Environment 
Design and program 
structure 


People 
Involved 
Users of the system 
Maintenance staff 
Original development 


(i) The i 
appropria y provide an encapsulation of best or at least most 


 oÞTlate, practice i 
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lard avoids the repetition of past mistakes. å 
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d impact | 
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hat the 
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ig, 1.11 Components ips more expensive ie’! Within an ona onti 
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The development of software engineering project standard 
and time consuming process. Various national and Gen NÊ 
the US DOD, ANSI, BSI, NATO and the IEEE have been active ; 
production of standards. These are general standards that can be aı o in the 
a range of projects. Various bodies such as NATO and qû 


organizations may require that their own standards are followed in softw: 
contracts. 


is a difficli 
odies such al 


Various standards have been developed covering software engineering 
terminology, programming languages such as Ada and C++, notations such 
as charting symbols, procedures for deriving and writing software 
requirements, quality assurance procedures and software verification and 
validation processes. 


Quality assurance teams, who are developing standards should normally 
base organizational standards on national and international standards. Using 
these standards as a starting point, the quality assurance team should draw up 
a standards ‘handbook’. This should define the standards that are appropriate 
for their organization. Examples of standards that might be included in such a 
handbook are shown in table 1.1. 


Table 1.1 Product and Process Standards 


Product Standards Process Standards 


Design review form require- | Design review conduct submi- 

ments document structure. ssion of document to CM. 

Procedure header format Java Version release process project 
i lan approval process. 

programming style. p 

Project plan format change Change control process test 

request form. recording process. 


oftware project. 


0.34. Give the five staffing principles for s 
oject are as follows — 


Ans. The five staffing principles for software pr' 
(i) The principle of top talent, use better and fewer peop a a 

al 

Gi) The principle of job matching, fit the tasks to the skills 


motivation of the people available. 


ïi inci gression, 

(iii) The principle of career pro: : 

in the long run by helping its people to self-actualize. bt ee 
(iv) The principle of team balance, select people who w! 


and harmonize with one another. 
(v) The principle of phase out, 


an organization does best 


eam doesn't 


keeping a misfit on the t 
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0.35. Write short note on project planning. 
Or 


Explain the term project planning. (R.GPV., June 2014) 


Ans. Effective management of a software project depends on thoroughly 
planning the progress of the project. The project manager must anticipate 
problems which might arise and prepare tentative solutions to those problems. 
A plan, drawn up at the start of a project, should be used as the driver for the 
project. This initial plan should be the best possible plan given the available 
information. It evolves as the project progresses and better information becomes 
available. 

The pseudocode shown in fig. 1.12 describes the project planning process 
for software development. It shows that planning is an iterative process which 
is only complete when the project itself is complete. As project information 
becomes available during the project, the plan must be regularly revised. The 
oyerall goals of the business are an important factor which must be considered 
when formulating the project plan. As these change, changes to the project 
plan are necessary. 


Establish the project constraints 
Make initial assessments of the project parameters 
Define project milestones and deliverables 
while project has not been completed or cancelled loop 
Draw up project schedule 
Initiate activities according to schedule 
Wait (for a while) 
Review project progress 
Revise estimates of project parameters 
Update the project schedule 
Renegotiate project constraints and deliverables 
if (problems arise) then 


Initiate technical review and possible revision 
end if 
end loop 


Fig. 1.12 Project Planning 


e a err es starts with an assessment of the constraints (required 
Carried out û dr available, overall budget, etc.) affecting the project. This is 
Structure, size Junction with an estimation of project parameters such as its 
deliverables ae distribution of functions. The progress milestones and 
)e project is diraw en defined. The process then enters a loop. A schedule for 
Yen permissio n up and the activities defined in the schedule are initiated or 
‘Progr 8: is re; on to continue. After sometimes (usually about 2-3 weeks), 
Pista Lı eê and discrepancies noted. Because initial estimates of 
eters are tentative, the plan will always need to be modified. 


ZER iter 


iene 
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À Project managers revise the 
information becomes available. The 


ass i n) 
Sumptions about the proj i 
Project as q 


Ed y replan the proj lore 
elayed, they may have to renegotiate the Wer u chedule. Ifthe order 
raint: \ 


with the customer. If thi iati , 
û S renegotiation is unsucce: 5 and deliver bi 
ssful and the sch an 
Schedule canngg 


be met, a project technical review hi 
a may be held. The obj 
û bjective Of this 
1S review is 


to find some alternative a 
pproach to developme: i ithi 
constraints and meets the schedule. u LL Belaş 


Of course, wise proj 
$ ject managers do i 

Bec Canon g not assume that all will go well, 
ena Tip ion nearly always arise during a project. The 
initial assumptions and scheduling should be pessimistic rather than optimistic. 
There should be sufficient contingency built into the plan that the project 
constraints and milestones need not be renegotiated every time round the 
planning loop. 


Q.36. What is the objective of project planning ? (R.GP.V., June 2015) 


Ans. The objective of project planning is to provide a framework that 
enables the manager to make reasonable estimates of resources, cost and 
schedule. These estimates are made within a limited time frame at the beginning 
ofa software project and should be updated regularly as the project progresses. 
In addition, estimates should attempt to define best case and worst case 
scenarios so that project outcomes can be bounded. 


9.37. Write short note on project management plan (PMP). 


Ans. The project management plan (PMP) document must pa a 
necessary information to all three sets of people. Infosys's PMP includes a 
major sections. The first section consists of the SE z ae 

j s 

i i tion about the project. The second section 1 a 

eee E wen i lanning activitles. The thir 
i i bes the outputs of various p anning i j 
BR a Xe = 11 mechanisms to be used in the pa 
> Bey an ‘oles and responsibilities © 
for tracking. tne 
ous people involved — : 
(i) Project Summary — This section ae at 

the project. Tt includes information on the start and e! 


r end, project 9 
$ ntacts at the customer CR. 
the project eee z the customer, and assumptions made. D 
commitment 


may also be described. w 
(ii) Pro 
the various project: Plann 


t tracking, it specifies al 
final section describes the r 


high-level overview of 
d dates of the project 
bjectives, major 
etail of billings 


vari 


— This section gives the ce of mete 
res. It specifies the life cy eine ina 


to be A D: 
ife-cycle process 10. timation: 
life eyi jg section is effort es! isk 


The tailoring guidelines permit the 
controlled 
The estimates 


ity plan an 


management plan are also given in the PMP. The PMP also lists projects 


milestones. 

(iii) Project Tracking — Project tracking involves monitoring the 
activities, issues, quality, and other aspects of the project. In the PMP, how 
activities, issues and customer feedback will be tracked is specified. Policies 
regarding who will log the information, who will review it, who will close the 
activities, when they will be escalated and so on are mentioned. The frequency 
of the various types of status reporting is also specified. The focus of the 
project tracking mechanisms is capturing and resolving problems at the project 
level. 

(iv) Team — The project team must be properly organized to achieve 
optimal performance. At Infosys, generally a hierarchical team structure is 
employed, this team is headed by a project leader (PL). The PL reports to the 
business manager (BM) and to the customer representative. The PL may have 
either module leaders or developers (DVs) as subordinates. In addition, the 
configuration controller (CC) and the Database Administrator (DBA) typically 
reports to the PL. i i 


The team organization for the project is specified in the PMP. The logical 
ee of each person are detailed, along with start and end data for 
cach person. Finally, the implications and responsibilities of each 1 
project are specified. : aT 


9.38. How can enhanced the team effectiveness ? Give some attributes. 


eee enhance team effectiveness, software project managers require 
cane ership qualities. There are some difficult attributes of successful 
project managers that deserve much more attention as follows — 


@ Customer-interface Skill — Avoid adversarial relationship 


betwee i 
n stakeholders is a prerequisite for success. 


üi) Decisi ing Skil 
de 2 er miting Skill — A good leader when run into one, and 
8 skill seems obvious despite its intangible definition. 


. (iti) Hiri i in Bae 
the ri Kon Ss Skills = Hiring decisions are important decisions. Placing 
get, right job seems obvious although is surprisingly hard to 


fiv, i i 
totic bac Ske = Successful project managers must sell all 
akain the status eee Priorities, sell candidates on job positions, sell 
comp objectives, in In the face of resistance and sell achievements 
mise ang cone selling needs continuous negotiation, 
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(v) Team-building Skill— Teamwork needs that a manager b ’ 
trust, motivate progress, exploit eccentric prima donnas, transition Ê 


people into top performers, eliminate misfits, and consolidate diverse opis ) 
Tî 


into a team dirşction. 


0.39. How can improving automation through software environments ? 
Explain. 


‘Ans. An environment and tools employed in the software process generally 
have a linear effect on the productivity of the process. Some important tools 
like test tools, quality assurance analysis tools, planning tools, requirements 
management tools, editors, compilers, visual modeling tools and user interface 
are give crucial automation support for evolving the software engineering 
artifacts. The foundation for executing and instrument the process is given 
by the all given configuration management environments. The isolated impact 
of tools and automation generally permits improvements of twenty to fourty 
percent in effort at first order. But, tools and environments must be viewed as 
the primary delivery vehicle for process automation and improvement, so 
their impact can be much higher. 


Automation of the design process provides payback in quality, the ability 
to estimate costs and schedules, and overall productivity using a smaller 
team. 


Round-trip engineering describe the key capability of environments that 
support iterative development. As we have moved into maintaining different 
information repositories for the engineering artifacts, we need automation 
support to ensure efficient and error-free transition of data from one artifact 
to another. Forward engineering is the automation of one engineering artifact 
from another, more abstract representation. For example, compilers and 
linkers have provided automated transition of source code into executable 
code. 


Reverse engineering is the generation or modification of a more abstract 
representation from an existing artifact. > 


Economic improvements associated with tools and environments. Tt is 
common for tool vendors to make relatively accurate individual assessments 
of life-cycle activities to support claims about the potential economic impact 
of their tools. For example, it is easy to find statements such as the following 
from companies in a particular tool. : es, 

G) Maximum fifty percent of a project resources is used by test 
activities. Pepe ay ARY é 
`... G) Aboutfifiy percent of software development effort and schedule 
is consumed by unit testing and coding activities. _ i 


Convention; 
be al Softw 
(iii) Forty percent of life cycle ç are Management 35 


requirements analysis. Osts is used by evoluti Û 
On anı 


(iv) Software design activities have an į 


percent of the resources. Mpact on more than fifty 
i 


(v) Maximum twenty five 
i percent of rego, 
Ur 
project can be consumed by change management and cont etra 
1guration control 
(vi) It's maximum thirty ji 
5 Ww ê i percent of project bud; 
business administration, project management and Er raja 


: ‘SS assessment. 

Q.40. List out some principles of co ii ‘ 
ventional software engi 

engineering. 


which are critical activities. 


Ans. Some most important princi 
ciples of conventi n 
are as follows — ional software engineering 


(i) Make Quality Number One Priori 
$ > i ‘iority — Mı 3 
place to motivate its achievement and quality r be blra put into 


(ii) High Quality Software is Possible - A! 
y ) — All techni tı 
quality considerably should be adopted. These techniques Eran 


rototyping, simplifyi i can A s Al 
Era g, simplifying design, conducting inspections and hiring the best 


r (iii) Give Products to Customers Early -The most effective way to 
A the real customer needs to give users a product and let them play 
with it. Better is to deliver a quick and dirty prototype early in development, 


gather feedback, write a requirements specification, and than proceed with 
full scale development. 


Eg (iv) Determine the Problem before Writing the Requirement— Most 
aan fare engineers rush to offer a solution for the problem given, without 
a standing the problem clearly. If the engineer’s perception of the problem 
is accurate, only then the solution may work, further, before we try to solve a 


P oen, be sure to explore all the alternatives and don’t be blinded by the 
obvious solution, 


qm (») Evaluate Design Alternatives- After the requirements are agrı ca 
i n, aa should examine a variety of architectures and algorithms. You 
th ma do not want to use an “architecture” simply because It was can 
a “quirements specification. 
(i) Use an Appropriate Process Model- There are dozen of process 
Models, waterfall, omen prototyping incremental, spiral, operafignat 
` eve g and so on. There is ho such thing as & anar 


se y a Each project should choose a process We a 
that project on the basis of corporate culture, wl 
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risks, application area, Volatility of Tequirements i 
requirements are well understood. > And the extent to y 


(vii) Use Different Lang Phas s 
eternal thirst for simple solutions to difficult problems Î “çûr industr û 
declare that the best development method is one thaı riven many to 


ê Fekî t uses the saı i 
through-out the life cycle. This is not the practice in any other ca 
discipline. 3 


Hages for Different 


(viii) Minimize Intellectual Distance - Dijkstra defined intellectual 
distance as the distance between the real world and computerized solution to 
the problem. But you can minimize intellectual distance using any design 
approach. Different human perceive different structure when they examine 


the same real world and thus construct quite different realities. 


(ix) Put Techniques before Tools - An undisciplined software 
engineer with a tool becomes a dangerous, undisciplined software engineer, 


(x) Get it Right before You Make it Faster — It is far easier to ma 
a working program run faster than it is to make a fast program work. Don't 
worry about optimization during initial coding. 


(xi) Inspect Code-- Project schedule should account for time to eee 
and correct every component. Inspecting the detailed design and oa irs 
proposed by Michael Fagan is a much better way to find error than testing. 


(xii) Good Management is More Important than Good eal 
The best technology will not compensate for poor management, + WE 
manager can produce great results even with meager cat” 
management motivates people to do their best, but there are no univer 
styles of management. 


i i with 

(xiii) People are the Key to Success _ ee rae T oan 

appropriate experience, talent, and training are key. T! Çê çe 
HN tools, languages, and process will su e Dê 
Si appropriate foots! languages, and process will probably fail. 


Bi ing 
(xiv) Follow with Care — Just because everybody D a 

does not make it right for you. It may be right, but you arena ae 

- icability to your environment. Object orientation, meas eral: 

= J nt, CASE, p ototyping -- all these might inc Nice 

Moses nadine Tet satisfaction. The potential of a oat 

is often oversold, and benefits are by no menns guaranteed or u! on 

did the engineers do wrong ?” Even when software fails, 
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‘The fact is that in any engineering discipline, the best methods can be used to 
roduce awful designs, and the most antiquated methods to produce elegant 

pi 

designs. 


Q.41. Explain the principles of modern software management. 
Ans. Top ten principles of modern software management are as follows — 


(i) Base the Process on an Architecture-first Approach —This needs 
that a demonstrable balance be got between the driving requirement. The 
architecturally important design decisions, and the life-cycle plans before the 
resources are committed for full scale development. 


(ii) Establish an Iterative Life-cycle Process — 
sophisticated software systems, it is not possible to define the e 
design the entire solution, build the software, then test the el 
sequence. Instead, an iterative process that refines the problem 
an effective solution, and an effective plan over several iterati 
a balanced treatment to all stakeholder object ~es. 


With today’s 
ntire problem, 
nd product in 
understanding, 
ions encourages 


(iii) Transition Design Methods to mp. 
Development — A component is a cohesive se of 
either in source or executable format, with a de 


hasize Component Based 
preexisting lines of code, 
ined interface and behaviour. 
(iv) Establish a Change Managemen. Environment—The dynamics 
ve development, including concurrent workflows by different teams 
on shared artifacts, necessitates objectively controlled baselines, 
F 6y) Enhance Change Freedom through Tools that Support Round 
Trip Engineering — This is a automation element. It is the environment support 
essential to automate and synchronize engineering information in different 


fo SEWA -ٌ -ٌ Ne 
»rmats. Change freedom a necessity in an iterative process, and establishing 
ên integrated envin 


‘Onment is crucial. 
This app to, Capture Design Artifacts in Rigorous, Model Based Notation — 
. Pproach supports the evolutii i i i textual 
esign notation: on of. semantically rich graphical and textual 


of iterati 
working 


et (vii) Instrument the 
SS Ags, i 
Tite ê essment — It is th, 


erived directly fro: 
4 (iii) A i - 
artifacts, De a demonstration based approach to assess intermediate 
cut On ning the current state of the product artifacts into an 
x Megration Onstration Of relevant scenarios stimulates earlier convergence 


Process for Objective Quality Control and 
e best assessment mechanisms are well defined 
m the evolving engineering. 


(x) Establish a configurable process that is economically scalable. 
No single process is suitable fo 


r all software developments. A pragmatic process 
framework must be configurable to a broad spectrum of applications. 


EE J; EET 
f 


SOFTWARE MANAGEMENT 
PROCESS FRAMEWORK 


Q.1. Explain the Phases of life cycle process. 


Ans. We must move toward a software manufacturing process which is 


driven by technological improvements in process automation-and component 
based devel 


opment to get economies of scale and higher return on investment. 
ere are two Stages of the life-cycle at first order — 


(i) The Engineering Stage — This stage driven by less predictable Beg 
but smaller teams doing design and synthesis activities. It is decomposed into 
two distinct ph: 


ases such as inception and elaboration. 


+ fi) The Productio 


n Stage — This stage is driven by more predictable 
ger teams doing cons 


truction, test and development activities. It is also 
posed into two Phases such as construction and transition. 
aes four phases (inception, elaboration, construction, transition) ra 
sa, process are loosely mapped to conceptual framework of the spira 
inertia of shown in fis 21 The size of the spiral model corresponds to the 


T he project with respect to the breadth and depth ofthe artifacts that 
: developed 


documen a tia Manifests itself in maintaining artifact consistency, 

Inereaseq Hop, Tegression testing, quality analysis and configuration control. 

hanging ia may have small, or at least very straightforward, impact on 
any given di 


i 2 ete component or activity. But, the reaction ` ad 
Planning Major requirement changes, major architectural changes, maj 
Nibseg Pits. > 


Ai Phases paler organizational perturbations clearly increases in 
Ih tig, nes. 


É Phase ea, the Phases are named after the primary equity me 
i “Wirements analysis, design, coding, unit test, system 


a mostly sequential pro 


before the next was start 


Transition 
Products 


Fig. 2.1 The Phases of Life-cycle Process 
Q.2. Write the features of life-cycle phases. 


Ans. The features of life-cycle phases are as follows — 

(i) The most important feature/idea is iterative development. Iterative 
development is sequentially expanding and refining a system through multiple 
iterations, using feedback and adaptation. 

(ii) Each phase has iterations, each having the purpose of producing 
an executable piece of software. The duration of iteration may vary from 
phase to phase. 


S 


Elaboration Construction Transition 

Fig. 2.2 Four Phases of Iterations 

iii is a lightweight process addressing the needs of small projects 
oe seine addressing the needs of large projects. 
early and continuous documentation of the most urgen! 
anning and keeping a follow up. This 
s of software development. 
UML to build 


Inception 


— to more 
(iv) It helps in 

and the most probable risks by proper pl: 

helps in mitigating the risks at early ere iy 
(v) It also uses visualization methods such a: 


Jexity of the system. 
models so as to understand the comp’ bedenê „işa 


(vi) It also uses use-cases as test Ci 
documentation and helps in designing- 


end-use! 


of the project, but al 


quality. 


ka aa eS 
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nt 
Software Manageme! : 
advantages of the life-cycle phases < 


dvantages and dis 
as follows — 


0.3. What are the a j 
The advantages of life-cycle phases ar oe Lae 

2 i hasizes on addressing Very early hij 

AY me a fixed set of firm requirements at the i 

hee doer Ang the requirements as the project evo ves. 

a strong focus on docum 


ns the software pro 


ents. 
apeo a duct itself, and its 


(iv) The main focus remail 


ge of life-cycle phases DA 


The important disadvanta; 3 Ee. 
é lementation guidelines, leaves the tailoring 


It fails to provide any clear imp 
entirely to the user. 


0.4. Explain the unified approach to software development. 


(R.GPV., June 2013, 2014) 


Ans. The Unified Software Development Process or Unified Process is a 
popular iterative and incremental software development process framework. 
The best-known and extensively documented refinement of the Unified Process 
is the Rational Unified Process (RUP). 

The unified software development process represents a number of 
component-based development models being proposed in the industry. The 
unified process, using the unified modeling language (UML), defines the 
system building components and the component connecting interfaces. And 
by using a combination of iterative and incremental development, it defines the 
system function by using scenario-based approach. It then couples function 


with a hitectural identi i 
wa, n arc l frame work that identifies the form the software will 


thon unified modeling language was developed in conjunction with the 
hee Pres Throughout the entire unified process lies the idea of creati 

lels of the system being constructed. Models represent abstract view: n 

S o 


the system from a particular point of view. These lel 
t 
î pi models are captured and 


The unified pocess is not si 
poe A wê sihr Saye. e. simply a process, but rather an extensible 


O 


42 Project Management 


avoid potential issues of copyright infrin 


i ementsi ` 

and RUP are trademarks of IBM, The Û ar since Rational Unified 

titled The Unified Software Development see yaa TOcess 
0- 


201-57169.9) 
ames Rumbaugh, 
are have Published 


î S authors affili 
e name Rational Unified Process, DÎ 


: The Unified Process identifies core workflows that i 
software development process. These workflows include eee WU 
Requirements, Analysis, Design, Implementation and Test. The coe 
are not sequential and likely will be worked on during all ai the eee 
The workflows are described separately in the process for clarity but E 
in fact run concurrently. 5 


Q.5. What are the characteristics of unified process ? 
(R.GP.V., Dec. 2008, 2016) 


Ans. The Unified process has three distinguishing characteristics. These 
characteristics are — 


(i) Use-case Driven — The process employs Use-cases to drive the 
development process from inception to deployment. 


most 
(ii) Architecture-centric — The process seeks to Ti ona He 
significant static and dynamic aspects in terms of software a, şê Were 
architecture is a function of the needs of the users and is captur 
Use-cases. er i 
i Cc! 
-projects. “^ 
j An iteration 
Janne 


l — The process recog 
r projects or mint 
Its in an increment. 
e iterations a" pi 


(iii) Iteratiye and Incrementa 
practical to divide large projects into smalle: 
mini-project comprises an iteration that resu m 
may encompass all of the workflows in the process. 
using Use-cases. 


3 s cycle ? 
Q.6. What are the different phases of a ep GP. A June 2017) 
Ans. The unified process consists of cyc 
long-term life of a system. A cycle eon wê 
Elaboration, Construction, and Transition. cile four ph 
release, there are also releases within a cycle. ae 
discussed below — 


re j 
e the col out 
: + nception Phase ` j confir" 
(i) Inception Phase -- During the inceptin iew gu “he busin 
developed into a product vision. 


In this phase, van ndersa” 
understanding of the core business drivers. We wan! 


` and designs. 
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case for why the project should be attempted. The inception phase establishes 
the product feasibility and delimits the project scope. 


(ii) Elaboration Phase — During the elaboration phase the majority 
of the use cases are specified in detail and the system architecture is designed. 
This phase focuses on the “Do-Ability” of the project. We identify significant 
risks and prepare a schedule, staff and cost profile for the entire project. 


(iii) Construction Phase — During the construction phase the product 
is moved from the architectural baseline to a system complete enough to 
transition to the user community. The architectural baseline grows to become 
the completed system as the design is refined into code. 


(iv) Transition Phase — In the transition phase the goal is to ensure 
that the requirements have been met to the satisfaction of the stakeholders. 
This phase is often initiated with a beta release of the application. Other activities 
include site preparation, manual completion, and defect identification and 
correction. The transition phase ends with a postmortem devoted to learning 
and recording lessons for future cycles. 


Q.7. What is agile software development ? Write down its principles. 


Ans. Agile software development defines an approach from software 
development under which requirement and solutions evolve through the 
collaborative effort of self-organizing cross-functional teams and their 
customers and users. It advocates adaptive planning, early delivery, evolutionary 
development and continuous improvement and it encourages rapid and flexible 
response to change. 

Following are the principles of agile software developments — 

(i) Customer satisfaction by early and continuous delivery of 
valuable software. 

(ii) Accept changing requirements, even in late development. 

(iii) Working software is delivered frequently (weeks rather than 
months). 

(iv) Daily Cooperation between business people and developers. 

(v) Projects are built around motivated individuals, who should be 
trusted. 

(vi) Face-to-face conversation is the best form of communication. 

(vii) Sustainable development, able to maintain a constant pace. 

(viii)Give priority to technical excellence and good design. 

(ix) Simplicity is necessary. 

(x) Selforganizing teams provides best architectures, requirements, 
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(xi) Teams regularly tr 
x YS to become m 
development and adjusts accordingly. © more effective in Soft 
È Ware 


Q.8. Describe the rup and agile process. 


(R.GPy, 

Ans. Çı “ty Dec, 

aie m ae manne A software development Process fj cee 
, &up”. The full form of Rup is “Rational Unified p: Tom rotational jg 

of “IBM”. It divides the develo: Tocess” J 


\ pment process into four 
business modeling, analysis and design, implementation, XE 


The four stage of Rup process are as follows — 


ee (i) Inception = In this stage we thing about time Teso 
a our; Idea for the Project is started. The project team ene 
project is worth pursuing and what resources will be needed ae 


zadi (ii) Elaboration — In this stage the developers consider possible 
application of the software and costs related with the development. The 
project’s architecture and required resources are further evaluated. 


(iii) Construction — In this stage software is written, designed and 
tested, i.e., the project is fully completed. 


(iv) Transition — In this stage software is launched publically for 
testing. Final adjustments or opdates are made based on feedback from end 
users. 

The Rup development methodology provides a structured way for 
companies to envision create software programs. Since it provides a sete 
plan for each step of the development process, it helps prevent resource 
from being wasted and reduces unexpected developments cost. 


methodology is an process 
iffers significantly fon 
uickly and easily an 

ment methologies 


Agile Process — Agile software development 
for developing software. However, agile methodology di 
other methodologies. Agile means ability to move q î 
responding swiftly to change. In traditional software ge ha ; 
like waterfall model, a project can take several months TA Û nplelîêf 
and the customer may not get to see the end product ae 3 
the project. At a high level, non-agile projects enê rê E 
time for requirements gathering, design, dÊ Weye 
acceptance testing, before finally deploying the ea P aish pre-e 
has iterations which are shorter in duration a E one oF mo rei 
features are developed and delivered. Agile ate Ar Aeration 
and delivers the complete product at the end o: 

In agile methodology the delivery of suche 
is paid to the good design of the Pe 
interactions are required between the bus! 


this mati ar 
people 


aoe al 
e is unremitting" e daily 
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i e 
are accepted even in the later stages of th 


le methodology, the documentation 1S çev 
requirement is not very clear hence i 

ojects following the agile 
sks which can affect the 


in the requirements a 
However, in agl 
his methodology, the 
ict the expected result. The proj 
have to face some unknown ri: 


Changes 
development. 
Sometimes, in t 
difficult to pred 


methodology may e 
development of the project. 


lain in detail about inception phase. 


Ans. The main goal of this phase is to get agreement among e. F 
e-cycle objectives for the project. This phase brings to io a origin: eae 
of a potential product, and transforms it into an actual project. Its purpose i 
establish the business case for a new product or a major update and to specify the 
project scope. The primary objectives of the inception phase are as Da 3 

First is, establishing the project’s software scope and boundary conditions, 
having an operational concept, acceptance criteria and a clear understanding 
of what is and is not intended to be in the product. 

Second is, discriminating the difficult use cases of the system and the 
primary scenarios of operation that will drive the major design trade-offs. 

Third is, demonstrating at least one candidate architecture against some 
of the primary scenarios. 


0.9. Exp 


the li 


Fourth is, estimating the overall cost and schedule for the entire project. 
Fifth is, estimating potential risks. 
Some essential activities of the inception phase are as follows — 


wW Formulating the Scope of the Project — This activity involves 
capturing the requirements and operational concept in an information repository. 
a Ê San. the Architecture = Some assets are evaluated like 
SON Pro em space ambiguities and available solution-space etc. 

Fo Md q UT enning, and Preparing a Business Case — Alternatives for risk 
Saa 5 g, iteration plans and cost/schedule/profitability trade-off are 


The outcomes of the inception phases is shown in fig. 2.3 


Prototypes Project Plan 
Business i 
Susie Inception Initial Risk 


Assessment 


Vision it iti; 
Initial U: Initial Business 
Di se 
ocument Case Model Initial Case 
Project 
Gh 
Fig. lossary 


2.3 Outcomes of Inception Phases 
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0.10. Explain in detail about elaboration phase. 


Ans. The purpose of this phase is to more thoroughly analyze th 
domain, to define and stabilize the architecture and to address the higtfes 
elements of the project. In this phase an executable architectual prototype is 
built in one or more iterations, depending on the scope, size, risk and novelty 
of the project. This addresses at least the top key use cases identified in the 
inception phase, which typically expose the top technical risks of the project. 
This is an evolutionary prototype of production quality components is always 
a goal, it does not exclude the development of one or more exploratory, throw- 
away prototypes to mitigate specific risks like design/requirements trade-offs, 
component feasibility analysis, or demonstrations to investors. 

The primary objectives of elaboration phase are as follows — 
G) Defining, validating and base lining the architecture as rapidly 
as practical. 
(ii) A baseline product Vision based on an analysis model. 

(iii) Demonstrating that the baseline architecture will support this 

vision for reasonble cost in a reasonable time. 

(iv) A resolution of the risks sufficient to make a “high fidelity” 
cost, schedule and quality estimate of the construction phase. 

Some essential activities of the elaboration phases are as follows — 

(i) Elaborating the Vision — This activity involves establishing a 
high fidelity understanding of the most critical use cases that drive the 
architectural or planning decisions. 

Û (ii) Elaborating the Architecture and Selecting Componen!s - 
Potential components are evaluated and make/buy/reuse decisions are 
sufficiently understood to determine the construction phase cost and schedule 
with confidence. The selected architectural components -are integrated and 
assessed against the primary scenarios. Lessons learned from these activities 
may well result in a redesign of the architecture, taking into consideration 
alternative designs or reconsideration of the requirements. 

(iii) Elaborating the Process and Infrastructure - The construction 

Zi the tools and process automation support, and the intermediate 
milestones and their respective evaluation criteria are established. 
The Sureome of the elaboration phase are as follows — 
e A A use-case model (80% complete) — all use cases having bee? 
Bo ae in the use-case model survey, all actors having been identified, 2 
-case descriptions (requirements capture) having been developed: 


(ii) Supplementary requirem« 2 ê uire- 
- ents capturing the non functional re! 
ments and any requirements that are not associated with a specific US€ Cee 
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(iii) An executable architecture and accompanying documentation — 
the software architecture document, including use-case descriptions (design) 
for a subset of use cases (use-case view), and an updated glossary. 


(iv) A revised business case. 
(v) A revised risk list. 
(vi) A development plan for the overall project, including the coarse- 
grained project plan, showing iterations and evaluation criteria for each iteration. 
(vii) A preliminary user manual (optional). 
The outcomes of the elaboration phase is shown in fig. 2.4. 


Development Plan Revised Risk 
Document 
Preliminary Elaboration An Executable 
User Manual Architectural 
Prototype 
Use Case Supplementary Architecture 
Model Requirements Description 


with Non Functional Document 
Requirement 


Fig. 2.4 Outcomes of Elaboration Phase 
0.11. Explain in detail about construction phase. 


Ans, Construction was the largest phase. In this phase, the team developed 
the new system in small increments called iterations. An interation consists a 
series of steps performed over a short. The steps included picking up the 
features to be implemented, refining bugs, designing the features, implementing 
the design (including testing and creating documentation), deploying an 
executable release of the software to obtain owner’s feedback. The successful 
completion of each iterations ended with a user acceptance test. 

During the construction phase, all remaining components and application 
features are developed and integrated into the product, and all features are 
thoroughly tested. The construction phase is, in one sense, a manufacturing 
process where emphasis is placed on managing resources and controlling 
Operations to optimize costs, schedules, and quality. In this sense, the 
management mindset undergoes a transition from the development of intellectual 
Property during inception and elaboration, to the development of deployable 
products during construction and transition. 

Many projects are large enough that parallel construction increments can 
be spawned. These parallel activities can significantly accelerate the availability 
of deployable releases; they can also increase the complexity of resource 
management and workflow synchronization. A robust architecture and an 
understandable plan are highly correlated. In other words, one of the critical 
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qualities of the architecture is its ease of construction. This is one rgasorwhy 
the balanced development of the architecture and the plan is stresged d ring 
the elaboration phase. | 
The construction phases has the following objectives — 
(i) Achieving useful versions (alpha, beta and other test releases) | 


in a timely fashion. 
(ii) Minimizing development cost. 
(iii) Achieving adequate quality as rapidly as practical. 
Some essential activities are as follows — | 
(i) Management and optimizing resources. 
(ii) Complete the analysis, design, implementation and testing of all 
required functionality. 
Gii) Assessment of product releases against acceptance criteria. | 
The outcome of the construction phase is a product ready to put in hands 
of its end-users. At minimum, it consists of — 
(i) The software product integrated on the adequate platforms. 
(ii) The user manuals. 
(iii) A description of the current release. 
The outcomes of the construction phase is shown in fig. 2.5. 


Test Outline Operational Manuals 


Test Suite 


Constru 


Documentation 
Manuals 
Software A Description 
Product User Manuals ofthe 
Current Release 


Fig. 2.5 Outcomes of the Construction Phase 
The evaluation criteria for the construction phase involve answe! 


questions — i 
(i) Is this product release stable and mature enough to be deplo 


in the user community ? 
(ii) Are all stakeholders ready for the transitio 


ring these 


yed 


n into the Use! 


community ? ed 
Gii) Are the actual resource expenditures versus planned expe 
: still acceptable ? ee TE 


Transition may have to be postponed by one release if the 


reach this milestone. 
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0.12. Explain transition phase with primary objectives. 


s ne poi pose of io transition phase is to transition tl ft 
product to the user community. Once the product has ezan Ya he software 
user, issues usually arise that require you to E zi en to the end 
some problems, or finish the features that were pannel releases, correct 


The transition phase is entered wh ine i 
r en a baseline is mature eno 
$ N - ugh to bı 
pogei n the end-user domain. This typically requires that dae tbe 
subset of the system has been completed to an acceptable level aiiin and 
that user documentation is available so that the transition to the user will r ide 
positive results for all parties. This includes — ae 


gerr 
TENI 


(i) Beta testing to validate the new system against user expectations 

(ii) Parallel operation with a legacy system that it is replacing 

(iii) Conversion of operational databases 

(iv) Training of users and maintainers 

(v) Roll-out the i istributi 
si product to the marketing, distribution, and sales 
ae a wa phase focuses on the activities required to place the software 
da e of the users. Typically, this phase includes several iterations, 
Ek ing beta releases, general availability releases, as well as bug-fix and 
ee releases. Considerable effort is expended in developing user- 
a EÛ ocumentation, training users, supporting users in their initial product 
e E ae feedback. At this point in the life-cycle, however, 
X ack should be confined primarily to product tuni 5 ie 

£ tun ci 
installation, and usability issues. oat eee amd 
TI a T: eh 
he primary objectives of the transition phase are as follows - 

(i) Achieving user self-supportability. 

E oe Arhive stakeholder concurrence that deployment baselines 
and consistent with the evaluation criteria of the vision. 


as Paes Achieving final product baseline as rapidly and cost effectively 


This phas f 
e e can range from being very simple to extremely complex, 
8 on the type of product. For 
Whereas ; 
replacing a nation’s air-traffic Product User 


exampl 
ple, a new release of an existing 
control 
Release Beta Test Reports Feedback 
Fig. 2.6. Outcomes of the 


deskt, 
OP product may be very simple, 
Transition Phase 


System would be very complex. 


The out 
i rê en 
18 shown in pees transition phase 
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50 ji asition phase is the fourth important projec kere (information set) associated with proces 
Atthe end ofthe a tone. At this point, you decide if the obj@etr use ad hoc notations, including text, 
milesi . 5 
the product release n 


some : z 
d if you should start another development cycle. In required to capture the 
met, ani Ê 


T y W i or the next cycle. 
i i tion phase for tl : 
milestone ma coincide with the end of the incepi p rS ders, Artifacts dı 
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lescribed in this 
ess case, document plan, work 
€ specification and environment, 


Tequirements set, deployment set, 


i it se involvi ú 2 i A 
T evaluation criteria for the transition pha management set” can also include a busin 
e 


Ê breakdown structure, status assessment releası 
to these questions — 


i paneer satisfied 2 Û Engineering sets divided into four sets as u 
Gi) Are the actual resources expen f design setand implementation set. The first mechanism for evaluating the evolving 

ality of every artifact set is the transitioning of information fr 

i lere edû q 'om set to set, 
expenditures sti e 


= çi Têr | thereby maintaining a balance of understanding among the requirements design, 
SS — THE ARTI ARTI î implementation and deployment artifacts. Each of these sets defined in fig. 2.7. 


ditures versus planned 


THE PROCE: 
ARTIFACTS OF THE > NG | r a ; 
MANAGEMENT ARTIFACTS, NTS DL wê (ii) Requirement Set - This set is the primary engineering context 
PRAGMATICS u for evaluating the other three engineering artifact sets and is the basics for test 
cases. Specific requirements set artifacts include a vision document and 
-ٌ ifact of the process. 
Q.13. Describe the artifac 


fa complete software system, requirement model. Requirements set artifacts are evaluated, assessed, analyzed 

a cı û j 

Ans. In order to manage the eee HE zl line and measured based on the following — 
gi ons of in 


wits. sons lete aspect of the system where as artifaot : (a) With the release specifications of the “management set’ 
ê sents a comp! Û ingle Consistency analysis. 
artifact sas; ee that is developed and elon asa meee y be 
nts interre: y ‘ eae 
ee e artifacts of the process are organized into Ave e R A 
= ee oe set, requirements set, design set, Iimpleme 
man: > 


deployment set. he management artifact capture the information necessary ; 

to synchronize stakeholder expectatio. R ts, design. (c) The consiste: î 
d i tw ê ncy, completene 

y i xpectations. he requirements, gn, bei 


mp: i tations th Syslog tion in the various sets is evaluated by the mapping against 
impli tation and deployment artifacts are captured in rigorous no! ; e design i E ©) Ea ae 
emeni t : 
i ort automated analysis and browsing. he artifact set process are plementation and de; Eagair 
that supp ployment se 
shown in fig. 2.7. 

The Artifact Set 


(b) Consistency analysis between the vision and the requirements 


(d) Changes analysis between the current version of the artifact 
to its previous version. 


(e) Review of other quality factors. 


l an dih (iii) Design Set - This set contains varying levels of abstraction 
j Ow the components of the Solution space. Specific design set artifacts 


incl - : 
Deployment ane design model, a test model and software architecture. Design set 
lementation are evaluat on the 
Set following - ated, assessed, analyzed and measured based 
A User" 


A Requirement [- A Test Model [> A Component ê (a) The internal Consistency and quality of the design model. 
i Pla odel ss les - ` ; 
eel Avion pees A Bouree o Run-time Fl! (b) The consistency with the requirements models. 
le ; i : à j a 
ieee pocument Architecture Û Associated e (c) Translation of artifacts from design set into the implemen: 
Deployment Description Compile-time ployment Sets, 
Document 


Status Assessments between ; (d) The consi 
Release Specification Tmation in thes 


Fig. 2.7 Overview of the Artifact Set Process 


istency, completeness and the semantic balance 
e set. 
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(e) Changes analyzed 


artifa: 


(iv) Implementation Set — 


shows the tangible impl 
essential for stand-alone testing 0 
translated into a subset of the deplo: 
artifacts include the component ex: 
associated compile-time files. Imp’ 
human readable formats which a 
measured based on the following — 


deployment set notatio: 
consistency and comp! 


(c) Executable files 
criteria. This assessment is done 


or testing. 
(d) Exe 
actual outcome. 


in design model corresponding to 


machine languages notations, 
scripts and executable target spe 


executable baseline and 


on the following — 


balance betwee! 


strategies described in th 
against the physical resources 
platform type, number an 


ementations 0 
f the components. This set can also be 


(a) Translation of artifact 
ns such as compilation and linking so as to 


Jeteness among artifact sets. 
(b) Consistency with 


through inspection, 


cution of test cases that compare expecte 


(e) Changes analysis 


(f) Review of other dimension 

(vy) Deployment Set — 
executable software and 
target environment. Specific deployment set a! 
associated run-time files. 


Deployment sets are evaluated, assesse 


(a) Tests conducted against the use! 


(b) Tests conducted on the 
e mapping com] 
d network topology- 


(c) Tests conducted against the 
user manual such as installatio! 


between the current version offthe 


cts in design model corresponding to its previous version. 
(f) Review of the other quality factor. 


This set contains source code which 
f components and any executables 


yment set. Specific implementation set 
ecutable, a source code baselines and 
Jementation set artifacts are written in 
re evaluated, assessed, analyzed and 


the design model. 
assessed against 


between the current version of the 
its previous version. 

of quality. 

ains user delivera 
build scripts, ins 
to use the produc 


This set cont 


cific data necessary 
rtifacts include the 


d, analyzed and meas 


iy requirements and 4! 
sem 


sistency. completeness a! 


attributes so as to evaluate the co! 
n the artifacts in the two sets. cation 


A al 
partitioning, replication and 
ponents of the “il 
of the deployment system suc 
«oş i! 
defined usage spehi on 
Jı 
n, user oriented dynamic ree nfig 


s from implementation set into the 
evaluate the 


the relevant evaluation 
analysis, demonstration 


d results with 


artifacts 


bles and 
tallation 
tin its 
user's manual, 


ured based 


implementa" pihe 
mp! PeT pat of th 
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) (d) Change analyzed between the current version of i 
in design model corresponding to its previous versions su - 


(e) Review of other dimerısions of quality. 
0.14. Differentiate between i j a 
implementation set and deployment set. 


Ans. The difference is important because the structur : 
vî ar ser is very different from the structure za +... 
T Ta a Ue set consists of the source A ies fie 
Wan TI - Ce ae code. The quality achiey u Û 
ee ees ot that attained in the design and impl Kudî A 

nt set consist of — plementation sets 


(i) Dynamicall 
Ê ly reconfigurabl 5 
time para - gurable parametı 
p mata buffer sizes, colour palettes and ee any type of run- 
are Er o issues in case of an iles. 
ver: ; 
versus hot backup. sus centralizi 
(iii) Impacts 
versus pee ofthe compiler/]i arama 
a optimization. piler/link optimizations like space optimizati 
A (iv) Issue. ization | 
€ conditions, 


j v 
collection . Yirtual machine co 


j y type of allocation s i 
st 
ed, primary and shadow threads oie 


s in process 
level Concurrency such as the dead] 
adlock and 


| 
i 


nstraints s 

uch as fil A 

tation: Û es descriptors 

s and maximum record Se ae 


e ın le ne 
pee perating system 
a crea nce or behaviour of the cate eae 
en are product. 
a u os St artifacts, 
many engineering disci 


testin, e 
g nce lo 
Phase 'ompl Phase ped simultaneo 
i 4 thr u 
lie vere > “te-life-cycle acti Sugh the deployme: sly along with the 
Yel Yel ctiv nt ph: 
itis e. That means, te ity that is el ded a ae means 
esting is st n each and eve: 
Ty 


NOt a late |: 
te Life 

t z cycle activi 

“St artifacts a Betivity: 


© unt 
t mmunicated, deve oped and engincered 


© developed product. 


are im 
plemented i 
ın program 
grammable and 


est art; 
, tifacts 
lo. are 
Sumented, documented in a similar 
Manner as 
any 
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(v) The test artifact developers use same tools, techn and 


training as that of the software developers use while developing th pr) duct. 
(vi) The test artifact are very project-specific. 


Q.16. State and explain various management artifacts. 


Ans. The management artifacts are not the product, but are used to drive 
or monitor the progress of the project, estimate the risk, adjust the resources, 
give visibility to the customer (in a contractual setting) or the investors. The 
management artifact set consist various artifacts that describe the intermediate 
results and the associated information that is required. To document the product/ 
process legacy, to maintain the product, to improve the product and to improve 
the process. 


(i) Work Breakdown Structure — WBS is a way of organizing project 
elements into a hierarchy that simplifies the tasks of budget estimation and 
control. It helps determine just exactly what costs are being estimated. 
Moreover, if probabilities are assigned to the cost associated with each 
individual element ofthe hierarchy, an overall expected value can be determined 
from the bottom up for total project development cost. WBS-based technique 
are good for planning and control. 


(ii) Business Case — A business case document, describing the 
financial context, contract, projected return on investment. This artifacts gives 
all the information that is required to decide whether the project is worth 
investing or not. It’s also describe the 'expected cost, expected technical and 
management plans and backup data necessary to face the risk and realism of 
the plans. The main objective is to transform the vision into economic terms 


which can help the organization to make an accurate assessment of return on 
investment. 


(iii) Software Development Plan - The software development plan 
(SDP) gives detail description of the process framework. That means a 
development plan document, which contains in particular the overall interaction 
plan, and plan for the current and upcoming iteration, Two main objectives of 
a software development plan are periodic updating, understanding and 
acceptance by managers and practitioners, 


and obj ees ecifications — This artifacts include the plan, scope 
nd objective evaluation criteria for each baseline release and all these details 
= cane from the vision statement as well as from many other sources 
pei analysis, risk Management concerns, architectural 
en ee ee constraints, quality thresholds. All these artifacts 
thus achieyi pecification evolve and get updated along with the process, 
‘eving greater fidelity and maturity in understanding the requirements: 
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(v) Release Descriptions - It describes the results of each release 
that includes the performance details against each of the evaluation criteria in 
the corresponding release specification. Release descriptions also describe the 
evaluation criteria for the configuration baseline and also provides substantiation 
i.e., through demonstration, inspection, testing and analysis of each criterion 
has been address as required. 


(vi) Software Change Order Database — Managing and tracking the 
changes is one of the important activities in iterative development process. As 
the iterative development process provides a ‘greater change freedom’, a project 
can be iterated again and again to achieve more and more productivity. This 
flexibility increases the content, quality, and number of iterations that a project 
can achieve within a given schedule. Change freedom has been achieved in 
practice through automation, and today’s iterative development environments 
carry the burden of change management. Organizational processes that depend 
on manual change management techniques have encountered major 
inefficiencies. 

(vii) Status Assessment — These artifacts provide periodic snapshots 
of project health and status, with metrics of progress, staffing, expenditure, 
results, critical risk, action plans and post mortem. 

(viii) Deployment — This artifacts includes several document subsets 
for transitioning the product into operational status. The deployment artifacts 
must include gathering additional information useful for transition, training, 
installation, sales market plans, manufacturing and cutover. 

(ix) Environment — Mostly, all the modem approaches define the 
development and maintenance environment as a first class artifact of the 
process. Such an environment includes requirement management, configuration 
management, automated regression testing, programming tools and visual 
modeling. 

` Q.17, State and explain various engineering artifacts. 

Ans. This set of artifacts is derived from the thorough engineering: notations 
such as of UML notations, programming languages Or executable machine a 
This engineering artifact set can be categorized into three kinds which are specially 
intended to give a more general review. These are as follows ~ 

(i) Vision document 

(ii) Architectural description 

(iii) Software user manual, 


(i) Vision Document - This document provides a Dan 
about the proposed software system that is under development. Itt 
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that support the contract between the development organization and fuming’ 
authority. This document involves changes progressively as understani ing 
evolves out of the requirement, technology, architecture and plan. A g 
vision document should change slowly at each and every phase of the life- 
cycle. A default outline for a vision document are as follows - 
(a) Feature set description 
(1) Priority and precedence 
(b) Quality attributes and ranges 
(c) Required constraints 
(1) External interfaces 
(d) Evolutionary appendixes 
(1) Use cases — It includes primary scenarios, tolerance 
and acceptance criteria. 
(2) Desired freedoms. 


(i) Architecture Description — This artifact provides an organized 
architectural view of the software that in under development. These 
descriptions are derived from the design model which includes the views of 
the design, implementation and deployment sets that helps in understanding 
how the operational concept of the requirements set are derived. The depth 
and breath of the architecture description varies from project to project 
based upon various factors. A default outline for a architecture description 
are as follows — 

(a) Architecture Overview - It consists objective, constraints 
and freedom. 

(b) Architecture Views - It consists design view, process view. 
component view and deployment view. 

(c) Architectural Interactions — This includes operational 
concept under primary and secondary scenarious, operational concept under 
anomalous conditions. 

(d) Architecture performance 

(e) Rationale, trade-offs and other substantiation. 


(iii) Software User Manual - The manual provides the user wi 
the references that are required to support the delivered software. Although 
content is highly variable across application domains, the user manual shon 
include installation procedures, usage procedures and guidance, OP a 
constraints and a user interface description, at a minimum. The user a 
should be written by the members of the test team, who understand e 
Perspective more clearly than the development team. 


_ 
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Q.18. Write short note on technical artifacts, 


Ans. These artifacts are either the delivered goods — executable software 
and manuals, or the blueprints that were used to manufacture the delivered 
goods — software models, source code, and other engineering information 
useful to understand and evolve the product. The 


(i) User’s Manual, developed early in the life-cycle. 

(ii) Software documentation, preferably in the form of self- 
documenting source code, and modas (uses cases, class diagrams, process 
diagrams, etc.) captured and maintained with appropriate CASE tools. 

(iii) A Software Architecture document, extracted (abstracted) from 
the software documentation, describing the overall structure of the software, 
its decomposition in major elements — class categories, classes, processes, 
subsystems, the definition of critical interfaces, and rationale for the key design 
decisions. 

The artifacts enumerated in the entry and exit criteria in these three can 
all be mapped onto one of these 11 documents. 

Depending on the type of project, this typical document set can be extended 
or contracted, some documents can be merged. The documents do not have 
to be paper documents - they can be spreadsheet, text-files, database, 
annotations in source code, hypertext documents, etc. — but the corresponding 
information source must be clearly identified, easily accessible and some ofits 
history preserved. 


Q.19. Write down cultural issues of pragmatic artifacts. 


Ans. The cultural issues of pragmatic artifacts are as follows — 

(i) People are interested in reviewing the artifact but they don’t 
understand the language of the artifact because they do not have any knowledge 
of the engineering language in which the artifact is written and they don’t even 
care to learn it. “ka 

(ii) People are interested in reviewing the artifacts but don’t have 
any access to the tools because it is very often seen that the development 
organization are not fully tooled and the stakeholders rarely have any capability 
to review the engineering artifacts online. 

(iii) Human-readable engineering artifacts should use rigorous 
notations that are complete, consistent and used in a self documenting manner. 
(iv) A good document is self-defining and that gets used. 

(v). Papers tangible whereas electronic artifacts are too easy to change. 


9.20. What do 


you und Mi 
framework ae erstand by 


Software architecture ? What are 
(R.GP.V., June 2006) 


t ture offers conceptual 
architecture is the hierarchical pro; 


“ Bass, Clements, and Kazman define software archi 


system. Generally, sac eee me 
mponents. 


itecture in the following 


T i i 
= a software architecture of a program or computing system is the 
structure or structures of the system, which comprise software components, 
the externally visible properties of those components, and the relationships 
among them. 

One aim of software design process is to derive an architectural rendering 
of a system which provides a framework from which more detailed design 
activities are performed. 

Following are the set of properties that should be specified as part of an 
architectural design — 


(i) Structural Properties — These are the properties which define the 


ts are packaged and interact. 
nents and the way those componen! : 
See s — These properties of an 


i tie. 
ii) Extra-functional Properties r dee, 
hit at design address how the design architecture AA Geen 
La : r reliability, adaptability, capacity, security, an 
or pe 


Te 2 i ld 
ee milies of Related Systems — The architectural design shoul 
(iii) Fa 


tterns found in the design of families of related systems. 
attem: s 

er ai be able to reuse architectural 

fferent types of models used to repres 
structural mode! 


draw upon repeata 
In short, the design ; 
There are five di 
-s 
design. These are” 
ê collection of pro. 
enhance the 
found in similar app! ) 
view of the program 
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in iı i hitecture in the management, ‘perspective 
0.21. Explain in detail about arc! 
a Architecture is most critical and technical product of Pee 
& h includes parameters in infrastructure, control and data interface. 
r inated each other and makes hugs system. If there 
ble in the communication media and management 
y then lots of communication problems 
If the team members have good in inter 
he software architecture, must be 


project, whi 
All these parameters coordi 
are lots of languages availal 
team members having different literac; 
are generated which are never solved. 1 
project communications, as captured in tl 
accurate and exact. 
There are three different aspect of management perspective — 

(i) Architecture 

(ii) Baseline of architecture 

(iii) Description of architecture. 


(i) Architecture - It is design of software system. It’s also flows 
intangible design concept, All types of engineering which is useful to complete 
bill of material is part of it. Problem of whatever purchase and sale of the 
components are solved since custom component are elaborate. Cost of unit 
component and its assembling and construction cost is to be determined. 


e (ii) Baseline of Architecture — lt is tangible artifacts. They are 
satisfies the all stakeholders. All stakeholders are the Primary vision which 
includes the quality and function the vision set the business parameters which 
includes cost, profit, peoples, time, technology. 


(iii) Description of Architecture — It is i 
) “ -= an organized subset of 
amo Pani of from the design set model. It includes the text and 
tes which gives the complete informatio: 
3 í ompl n about the model. 
Sora neras about the intangible information for tangible artifacts. 4 
The importance of softw. 
software development proces: 


. (i) Gets basis o 
solution space, 


(iii) Encapsulates the cı i 
o i Ea 
eaten ee e TS between individual, various 


3 (iv) Proj : 
Immature process. 


ect uns i 
‘uccessful or failure Teasons — Dull Architecture and 


Soe 
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ature process and 


(v) Requirements are understandable int 
architecture should be previously demonstrated. 

(vi) Two important facts (a) Architecture development and (b) 
Process definition, 

0.22. Write a short note on software modeling. (R.G.P.V., June 2014) 
das a simplified version of a real system. It can 
portant for some applications 
blem increases, the perceived 


Ans, A model can be calle: 
be thought of as a model capturing aspects im] 
while omitting the rest. When the size of a pro es > perce 
complexity increases exponentially due to human cognitive limitations. 
Therefore, to develop a good understanding of any problem, it is necessary to 
construct a model of the problem. Modeling has turned out to be a very essential 
tool in software design and helps to effectively handle complexity ina problem. 

Different kinds of models are obtained on the basis of the aspects of the 
actual system are ignored while constructing the mode]. To understand this, 
let us consider the models constructed by an architect of a large building. 
While constructing the frontal view of large building, the architect ignores 
aspects like floor plan strength of the wall, details of inside architecture, etc. 
while constructing the f vor plan, he completely ignores the frontal view, thermal 
and lighting characteristics, etc. of the building. 

A model in the context of software development can be graphical, textual, 
mathematical or program code-based. Graphical models are very famous 
because they are simple to understand and construct. UML is mainly a graphical 
modeling tool. However, UML often needs separate textual explanations to 
accompany the graphical models. 

0.23. Write a short note on UML. 

Ans. Unified Modeling Language (UML) is a language used to create an 
abstract system scenario, by visualizing, specifying, constructing, and 
documenting various parts and components of the system into a representative 
model enabling software system development. UML has its syntax an 
semantics. It provides a set of notations, such as rectangles, lines, ellipses, 
etc., to create models of systems that would be useful in documenting the 
design and analysis results. son 

The main goals in the design of UML are as follows - 

(i) Offer users with a ready-to-use, expressi d visual 
- pressive, and V 
language to create models. = +: 4 
Gi) Offer a language and notations to enhance concepts t° hi 
order representation, == mio ıl 1c Doina 
(iii) Do not depend on OO languages. 


(R.GP.V., June 2014) 


modeling 


gher 


and behavioural aspects of the environmen 


. Fig. 2.8 shows the different UML diagram 
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technology. rapid application develo; 
portability. 


elo $ 
ER concepts such as component 
+ reusability, interoperability, and 


The following benefits are provided by the UML-b: 
(i) Enhances communi Tk 
(ii) Enhances the devel 
system. 


d modeling - 
cations among project teams. 


Oper’s insight and visualization ofthe complex 


(iii) Developers learn faster include 
| to i ê i 
A A lude the system’s intricacies 


Û (iv) Prototype design is more suitable, where the specific complexity 
of structure and behaviour is taken into account in each iteration. This enhances 
the system in increments, and part by part. 


orn What r e the different system views that can be modelled using 
? at are the different UML diagrams which b zêrê 
Beda eE? can be used to capture 

Or 

Explain the use of UML for object-oriented design. 

Û à (R.GP.V., June 2010, 2011) 

` Or 
What are the different system views that can be modelled using UML? 
(R.GPK, June 2015) 


Ans. In UML, a system is represented using following views (models) to 
describe the system from distinctly different perspectives — 

(i) User Model View — This view defines the functionalities provided 
by the system to its users. 

(ii) Structural Model View — This view represents the structure of 
the problem in terms of the types of objects required to understand the working 
of a system and to its implementation. 

(iii) Behavioural Model View — This view represents the interactions 
between various objects to realize the system behaviour. 

(iv) Implementation Model View - This view represents the 
structural and behavioural aspects of the system because they are to be built. 


(v) Environment Model View - This view represents the structural 
t in which the system is to be 


implemented, 
s which can be used to capture 


each of the views. 
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Behavioural View 
Sequence Diagram 


Str ii 

See Collaboration Diagram 

Object a State-Chart Diagram 
eran Activity Diagram 


User’s View 
Use Case Diagram 


Environmental View 


Implementation View 
Deployment Diagram 


Component Diagram 


Fig. 2.8 Different Types of Diagrams and Views Supported in UML 
Q.25. Explain in detail about architecture in the technical perspective 
view. 
Ans. We look towards software architecture via various different aspects 
which are structure of software system, behaviour, guidelines patterns about 
elements, collaborations and composition. In the design set, an architecture 
framework is defined in terms of views that are abstractions of the unified 
modeling language model. The all over information given in design model and 
architecture view is abstraction of the design model. Real system involves the 
four views (design, process. component and deployment) of ‘the design model. 
The purposes of these views as shown in table 2.1. 
Table 2.1 Design Model’s Four Views 
Purpose 


Express structures and functions of the design model 


important for every system. 

Express concurrency and control thread betw! 
views add as per complexity. 
Express implementation set structure add as per 


complexity. 


Design 
Process Se 


Components 


t add as peî 


Express structure of deployment se' 
complexity. y 


Deployment 


et which includes 
Jectronically an 


‘As shown in fig. 2.9 illustrated artifacts of the design si 
above various views and architecture description (captures e 


j 
í 
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collection of the unified modeling laı and views are defined with 


‘ ss nguage di S 
organized and abstracted view into design Heine ne The architecture 
shown in fig, 2.9. i 


Requirements Design 
O 


Implementation 


Deployment 


Depending Upon Complexity System 
as Various Models or Singi 
a Hen ing 
Model which is Combination of All 


Fig. 2.9 Organized and Abstracted View into Design Model 


The use i i 
n 6 E RE how the system’s critical use cases are 
diagrams, and nEn i e design model. It is modeled statically using case 
design view address a Yusing any of the UML behavioural diagrams. The 
‘Ts meses ê e basic structure and the functionality of the solution. 
“executing the ee the run-time collaboration issues involved in 
` lo; ical software BE ce ee deployment model, including the 
management, aS Gort po. ogy, interprocess communication and state 
elements of the i ponent view describes the architecturally significant 
‘Tealization GER Kosan set and addresses the software source code 
The ee perspective of the project’s integrators and 
ine „ including the ion view addresses the executable realization of the 
sical resources of the dı ion of logical processes in the distribution view to 
General. leployment network. 
fhe, J0» an architecture baseline should include the followi 
piteguiremenis inc include the following — 
rity telationships among f: a 
a de u lema ng features and qualities. 
ationships of si names, attributes, structures, behaviours, groupings, 
ignificant classes and components. 


-“velopers, 
N tem, iı 


ihe û 
des critical use cases, system-level quality objectives, 
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Judes source component inventory and bi 


In implementation inc ver 
st of all primitive componeñ 


materials such that number, name, purpose, CO: 
des executable components sufficient to demonstra! 


In deployment inclu : : : 
the critical use cases and the risk associated with achieving the system 
qualities. 


Q.26. Define workflow and explain software process workflow. 
Ans. A workflow is a sequence of activities that produces a result of 


observable value i.e., a useful outcome or deliverable. In UML terms, a 
workflow can be expressed as a sequence diagram, a collaboration diagram or 
an activity diagram. 

We have already learnt in the ‘software engineering’ subject about 


the various types of models such as the linear sequential (waterfall), 
incremental, concurrent, RAD, spiral, JAD that can be used for software 


development. 

All these models have five li 
design, coding, testing and deployment. 

Barry Boehm describes this “unified approach” of so 
in seven major work flows. These are as follows — 

(i) Management— This workflow involves planning and controlling 

of the process so as to achieve product and project goals. 
The purpose of the environment disciplin 


(ii) Environment — 
evolving the maintenance environment and automating the process. 
problem and 


t — It involves analysis of the , 
The purpose of this workflow is to elicit the 
uding their identification modelling and 


fe-cycle phases in common such as analysis, 


ftware development 


e to 


(iii) Requiremen 
determining scope of the project. 
requirements for the project, incl 
documentation. 

(iv) Design 
architecture and design artifacts. 

(vy) Implementation — The 
the organization of the implementation, 

the components. 


— The purpose of this workflow is to evolve 4 robust 


purpose of this workflow is to anr 
deployment artifacts and program" 


(vi) Assessment -- The purpose of this workflo 
duct quality. 


testing/evaluating the trends in process and pro: 
a (vii) Deployment — The purpose of this workflow is to *"* 
e software product is available for its end users. 
The activities level across the life-cycle phases as show’ 


ure tha 


a in fig. 2!” 
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Phases 


Management 
Environment 
Requirement 
Design 
Implementation 
Assessment 
Deployment 
see E 220 Activity Levels Across the Life-cycle Phases 
ese ae terious activities and outputs at various phases of 


Ans. The various activities and outputs at various phas 
pi phases of management 


Table 2. iviti 
le 2.2 Activities and Outputs of the Life-cycle Phase in Management 
Management Workflow 


Inception Prepare business J] Statement of work 
proposal, plan (SOW), RDD (Regq- 
project, analyze | uirements defini- 
requirement, tion and descrip- 
vision. tion, scope, win- 

a : win contract, SRS, 

iboration Plan development, Designing and 
modeling, design- | architecture models, 
pe and architec- | project organiza- k 
, organization | tion, WBS. BIBO 
‘of resources, Software develo- 
pment plan, Status 


Constructi 
û on 3 'assessıneni i 
nee, entation of | Project schedule, | Work A U 
fea a plan, moni-| tested products, | structure (WBS) 
aes control progressive 

lopment, status 
Coding, testing 


Artifacts 


Transition 
pains product | Packaged execu- 
Dment, peo | tables, plan for 
Ee eee oi guzier prepare: 
'omers ‘dness, user prepa- 
| redness 


66 Project Management 


Q.28. Explain various activities and outputs 
environment workflow. 


‘Environment Workflow’ 


Ans. This defines the infrastructural requirement} 
introduction of change management. It provides the software development 
organization with the software development enviroment both process and 
tools that are essential for the development team. The various activities 
and outputs of this workflows is shown in table 2. 


at v 


nisi 


3: 


Table 2.3 Activities and Outputs of the Life-cycle Phases in 


Environment Workflow 


Ans: This workflow is the core part of the Project lifi 
the product life-cycle. The activities and outputs of th r 
requirement workflow is shown in table 2.4. a 


2.4 Activities and Outputs at Various Phases of Requirement W 'kflow 
orl 


ious’ phases of 


allation and 


Life-cycle Phases Activities Outputs 


alternative develo- 
pment strategies, 

define developm- 
ent environment. 


mentation. 


Install the develo- 
pment platform 
using internal res- 
ource, meet the in- 
adequacies and 
non-availability 
through procure- 
ment. 
Maintain develop- 
ment environment, 
maintain software | needs 
change order data-| 
base 


Elaboration 


Construction 


To maintain envir- 
onment and soft- 
ware change order] deployment 


database 


Transition 


-~ 029. Explain various activities and outputs 
requirement workflows. i 


SRS analysis, find | Development plat- 
from in term of 
h/w and s/w, tools 
and technologies, 
Define for imple- 


Test database, ins- 
tallation of devel- 
opment platform. 


Ready to serve the 
s/w development 


Keep ready the cha- 
nged database and 


required environ- 
ment to receive beta 
| test s/w product 


Environment, 
Software change 
order database 


the 


e 
of the life cy ete pl 


A Workflow, 
ins. : Ê i 
oe effective design and its architecture with the baseline and 
es of ae ilt accordingly. The various activities and outputs at the various 
Ta 2 es is shown in table 2.5 

ties and Outputs at the Various Phases of Design Workflow 


Phases 
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-cycle as well as 
e-cycle phases in 


Requirement Workflow 


[demane] oupa —] 
Analyze requirem- | Defined operatio- 
ents, convert requ- | nal modules, logi- 


irements into ope- | cal sequence of 
rational modules. | development. 


upon the modules | to be designed ac- 
defined in incepti- oo 


oo 


on phase and bas- 

sed upon the expe- 

ctations set by the Requirement a 
set, Release a 


Study and evaluate} Definition of obje- apretar 


the different archi- | ctives and achieve- 


level of objective 
achievement. 


se plan, revisit and | release objectives. 
cross-check the 
release objectives. 


TEK Zan: 


Ji 


Explain various activities and outputs at the various phases of 


ù Logical and physi- 
chitectural conce- | cal model of the 
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Achieve architec- | Baseline architec- 

ture baseline using | ture. 

the conceptual 

model. Design sé 


Design components | Architecture 

of the achieved ar- | design 
chitecture. 

Refine architect- | Architecture des- 
ure and compone- | ign for deploym- 
nts so that it can | ent. 

be moved onto 

customer deploy- 

ment environment. 


Elaboration 


Construction Hed 
description 


Transition 


Q.31. Explain various activities and outputs at the various phases of | 


implementation and assessment workflow. 


Ans. Implementation Workflows — Implementation workflows 
programming the components and evolving the implementation and deployment 
artifacts. The various activities and outputs at the various phases of | 


implementation workflow is shown in table 2.6. 


Table 2.6 Activities and Outputs of the Life Cycle Phases in 
Implementation Workflow 


Implementation Workflow 


Architecture 


Assessment Workflow — 
deliverables and quality. The activiti 
assessment workflow is shown in tabl 
Table 2.7 Activities and Outputs at Various Ph 
Workflow 


Assessment Workflow 


ases of the Assessment 


Inception Assess plan, vision Architecture and 
prototypes like | refined design, 
build prototype and ; 
test prototype. 


Artifacts 


Elaboration 


Assess architecture,| Software product, 
design and develop 
software system, 


Release specifi- 
cations, Release 
: descriptions user 
Assess interim | Improved software] manual, Deploy- 
releases. product. ment set 


Construction 


Transition Assess product re-| Custo: ir accepta- 


leases, conduct nce. 
customer accepta- 
nee testing. 


9.32. Explain various activities and ou uts at the various phases of 


deployment workflow. 


A ae Transitioning the end products to end user. The activities and outputs 
lous phases of deployment workflow is shown in table 2.8. 


Table 2.8 Activiti 
d tie: i t 
as build prototype, Û s and Outputs at Various Phases of the Deploymen 


test prototype, eva- z Horko 
luate. Deployment Workflow 


Activities Artifacts 


Support architect- | Refined design 
ure prototypes such | and architecture. 


Elaboration 


Produce architect- | Software product. | Tmplementation | Phases | Artifacts 


ure baseline, desi- set, Deployment 
gn and develop set 
software system. 


Produce complete | Improved software 
componentry, rebl- | product, impleme- 
ease software for al- | ntation on deplo- 
pha and beta test- | yment platform. j x requirement speci- 
ing. - _| fication (SRS). 

Transition Maintain compon-| Customer accepta- ; Define user manu-| Completed user 
ents, conduct cus- | nce. al, make appropri- 
tomer acceptance ate changes based 
testing. 


nses, map the achi-| system completion. 
eved goals stated in 
RDD (requirement 
definition and de- 


Deployment set 


xazê 
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customer: 


als. 


Transition 
to user, 


0.33. Explain in detail 


: prop 
development 
determined by critical 


is shown in fig. 2.11. 


table 2.9. 


Release m 


transition materi- 


Transition product 


the software prod- 
uct, user manual. 


Ans. Iteration workflow 
ortions and also states wher 
life-cycle. Iteration 

use cases and high 


as we progress across the dı 


Allocated 
Usage Scenarios 


Fig. 2.11 The Workflow of an Tterat 


The various operational workflow: 
implementation, assessment (evaluatio! 


dikan een 


anual to| Handing over the 
s, prepare | system and getting) 
user acceptance. 


System closure as 
per the contract. 


handover 


about the iteration workflow of the software process. 


describes the sequenti: 
e the iteration is 
ion workflow is based 


evelopment life-cy 


‘Management Workflow 
Requirement Workflow 


Design Workflow 


‘Evaluation/Assessment ‘Workflow 


Deployment Workflow 


>¬ 


Result for the 
Next Iteration 


ion 
S, management, requirements» | 3 
n) deployment description is sho 


Table 2.9 


Description 


The purpose of the management disciplin ‘ 
(i) Iteration planning to determine the conten 
release. 


e is to T7 


al set of activities in various 
located in the project 
on iteration planning 
risk items and decreasing in priority 
cle. The workflow of an iteration 


Requirement 


Evaluation 


Implementation) T! 
he purpose of the implementation disci l 
1scipline is to — 


fan 


Mortem so th: 
+ o 
at lessons learned can be captured and 


(i) Analyzing the ee 

(ii) Baseline architecture : 

(iii) The baseline requireme 
the use cases to be a 
iteration and their Sit 


= -ٌ 
ent discipline is to 
plan. : 


Set arti 
artifacts to fully elaborate 


onstrated at 
û t the 
tion criteria. çarên ilig 


(i) Developi 

j) ping or acquiring 

(ii) Enhancing or modifying oo eA les 
eee: = 

(iti) To demonstrate the evaluati 

iteration. 


y existing components 
On criteria allocated to this 


The 
purpose of the evaluation (assessment 


ito ) discipline is 


(i) Evaluatin, 
g the results of the iteration, i 
i iteration. i 
ance with the allocated evaluation on a 
A of the current baselines: A 
li) Identifyi : 
Kendine ay rework required and determining whe. 
e performed before dı of this 
lepli i 
5 şe or allocated to the next ie Galak 
ssessi i î 
i ssing results to improve the basis of th S 
€ration’s plan. ia 
The p 
urpose of th i iscipline i 
A: e design discipline is to - 
ae ing the baseline architecture 
aseline desi i 
ke dese WR gn set artifacts to elaborate fully the 
lli) Test modı 
cl 
gera IÊ ements necessary to demonstrate 
aluation criteria allocated to this iteration. 


‘he Purpose of lo — 
3 rpose i 
Gi) the deployment discipline is t 


1) Transiti 
sitioni 
a ee the release either to an external 
gan or to internal closure by conducting a post- 


ng compli- 
and the quality 


L reflected i; 
‘ae in the next iteration. 


individu; 
laboran ual workflı 3 
oration focus e ow figures, it can be seen that iterations 
u Ons in o AENA management, requirements, anı 
Ons in transitio A focus on design, implementation, 
n focus on assessment and deployment. 
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The representation of individual iteration workflow is sgy 


Inception and 
Elaboration Phases 


Transition Phase 


Implementation 


Deployment 


Construction Phase 


Evaluation 


Fig. 2.12 Individual Iteration Workflows 


Q.34. Write the characteristics of iteration workflow. 


Ans. The characteristics of iteration workflow’s are as follows — 
G) The iterations include continuous assessment of risks and results 


that describe are — 
(a) Requirements 
(b) Design features and performance 
(c) Reviews and any changes that may occur 
(ii) Iterations represent the state of overall system architecture and 
also the progress status of complete deliverable system. 
Gii) Increment states the current work in progress that will be merged 
with the previous iteration to form the next iteration. 
0.35. What are the check points of the process ? 
ity.’ It measures (evaluates) 
stones can be set 1 
efining the scope, '” 


Ans. It is a well-defined ‘measure of an activ: 
an activity and its result with maximum certainty. Mile 
stakeholders meeting to discuss plans and progress, in dı 
achieving the test result etc. The purposes of this event are as follows — ‘ 

(i) Coordinates stakeholders (developers, customer ante 
expectations and achieves a win-win agreement on the re the desi? 


and the plan. 
(ii) Coordinates the related artifacts to a reliable, © 


quirements, 


consistent and 


balanced state. 
(iii) Identifiy the risk, issues and al: 


(iv) Conduct a global assessment 
Three types of joint management reviews con 
process as follows — 


‘tions: 
so the out-of-tolerance conditi 


55 
for the whole life-cycle pe the 
ducted through" 
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(i) Major milestones 
(ii) Minor milestones 
(iii) Status assessments. 


0.36. Explain three checkpoints in short. 
Ans. Three checkpoints are as follows — 

(i) Major Milestones - These are measured at the end of each 
phase as planned. These are termed as systemwide reviews since these are 
conducted at the end of each of all the four phases such as inception, elaboration, 
construction and transition of the life-cycle process. It gives idea of overall 
system issues, also synchronized and coordinates the project management 
and the engineering perspectives and also verifies whether or not the aim of 
the phase are achieved. Major milestones use formal stakeholder - approved 
evaluation criteria and release description. 

(ii) Minor Milestones — These are measured at the end of each 
a and sub-processes within each phase. Minor milestones are set 
ere oe the completion of a tangible result. It includes iteration 
ta at are performed to conduct a detail review on the content 
elene ee a authorize the continuation. It includes two artifacts a 
Loca Şe ion and a release description. Minor milestones use informal 
Hesena ee controlled versions of evaluation criteria and release 

ifacts. 
Process TE Grae Assessments — These are performed to measure the 
Assessments Bebe conten the completion of the goals of a A 
with frequent and se a periodically so as to provide the manageme : 
development gular insights of the progress being made in the projec 


Soe ea bes explain various stakeholders and their expectation for 
Ê dê nes reviewers. 
initia] op “Ai major milestones (life-cycle objective, life-cycle architecture, 
u sition nal capability and produce release major milestones) occur at 
1 various eu S between life-cycle phases. Major milestones are employed 
Model and s, Olutionary process models such as the conventional waterfall 
ave diffen J," In an iterative model, it happens that different stakeholders 
these different expectations and therefore, to achieve the conformance of all 
9Ê the four nt Stakeholders, some major milestones are set at the end of each 
Stakeholders Phases so as to achieve harmonious agreement among all 
and what z the current status of the project. The different stakeholders 
ir variant expectation are shown in table 2.10. 
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Stakeholders 


Customers 


Table 2.10 Major Milestone Rev 


Expectations 


They are concerned with the project schedule and budget 
estimates, feasibility, risk assessment, requirements 
understanding, project progress. 


They are concerned with requirements consistency anal 


their usage, potential to accommodate growth and quality 
features. 


Architects and 
systems 
engineers 


They are concerned with the product line compatibility, 
any changes in requirements, trade-off analyses, accom- 
plishment and consistency, risk assessment, quality, and 
usability features. 


Developers They are concerned with the sufficient details about the 
requirements and their respective usage scenario 
descriptions, frameworks for component selection and 
development, resolution of risks, product line compatibility, 


satisfactoriness of the development environment. 


They are concerned with the sufficiency of the product 
and related artifacts, project understandability, 
interoperability with existing systems, and satisfactoriness 
of maintenance environment. 


There are also many other stakeholders who are concerned 
with what’s happening in the project. These stakeholders 
may be regulatory agencies, independent verification and 
validation contractors, capital investors and sales and 
marketing teams. 


Q.38. What are the types of major milestone ? Discuss. 
‘Ans. There are four major milestone as follows — 

(i) Life-cycle objectives milestone 

(ii) Life-cycle architecture milestone 

(iii) Initial operational capability milestone 

(iv) Product release milestone. 


All these four major milestones occur at the end of each 
achieve the conformance of various stakeholders. 


phase so 8$ a 
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(i) Life-cycle Objectives Milestone— This milestone obtains at the 

d of the inception phase. It includes detailed plan for the elaboration phase, 
We d schedule estimates and expected benefits from the system. The vision 
“an and the critical issues about the requirements and operational concept 
of the system are addressed. It also contains a draft architecture and a prototype 


architecture demonstration. 


Goals — 

(a) To authorize all the stakeholders to advance to the 
elaboration phase including the plan, cost and schedule estimates, and 
expected benefits. 

(b) To achieve a successfully completed ‘life-cycle objectives 
milestone’ so that the project manager can get an authorization (or say a green 
signal i.e., the permission) from all the stakeholders to proceed towards the 
elaboration phase. 


(ii) Life-cycle Architecture Milestone - This milestone is set at the 
end of the elaboration phase. It includes detailed plan for the construction 
phases. Critical issues about the requirement and the operational concept of 
the system are addressed. This review will also produce vision Sues 
software development plan and evaluation criteria for the next milestone !.e. 
for the initial operational capability milestone. 

The baseline architecture that consists of both a human 
Tepresentation and a configuration-controlled set of software components that 
are captured in the engineering artifacts. It also contains a presentation and 
overview of the current status of the software project, a configuration-controlled 
Set of all engineering data such as the set of software components for wanan 
down in the engineering artifacts, an executable representation Orme 
capability. 


Goals — 


-readable 


(a) To demonstrate an executable architecture to all stakeholders. 


(b) To achieve a successfully completed ‘life-cy’ mc eee 
ture milestone’ so that the project manager can get an authorization from a 
the stakeholders to proceed towards the construction phase. The below 
figure lists the technical data i.e., reviewed by the life-cycle architecture 
milestone, Aj 
This milestone is 


dl aa Kene rê Gay arc apa lie) Au Ta instruction and 


sı : 
et at the end of the Construction phase. It includes installati 
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critical issues, software version descriptions, opera 
test environment and test software. 


fals, support for 


Goals - 
(a) To assess the readiness of the software so as to proceed 


towards product transition onto customer/user environments. 


(b) To authorize the beginning of acceptance testing. Acceptance 
testing is performed iteratively in iterations. 

(iv) Product Release Milestone — This milestone is set at the end of 
the transition phase. It consists acceptance test outputs, open issues, installation 


issues and support issues. 
Goals — 
(a) To assess the accomplishment of the software. 
(b) To assess the software transition. 
(c) To review the results of acceptance testing. 
(d) To address all the open issues. 


(e) To review all the software quality metrics and assess whether 
the reviewed quality features sufficient for software transition onto the support 


organization. 


Life-cycle Life-cycl ta 

fe-cycle le-cycle Operational Product 
Objectives Architecture Capability Release 
Milestone Milestone Milestone 


Fig. 2.13 Typical Sequence of Life-cycle Checkpoints 


0.39. What is the difference between iterative readiness review and 


iteration assessment review ? 


Ans. ln most of the iterations where one - six months duration is 
ifference 


required, there only two types of minor milestones are required. The di 


between interactive readiness review and iteration assessment review a° As 
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follows — 
(i) Iteration Readiness Review — 

(a) This is an informal milestone i.e., set at begin of each iteration. 

(b) It conducts detail review of iteration plan and its evaluation 
criteria. 

(c) Early iteration focuses on design and analysis, 
experimentations, and risk assessment. 

(d) Later iteration focuses on completeness, consistency, usage, 


and change management. 


(ii) Iteration Assessment Review — 

(a) This is also as informal milestone i.e., set at end of each 
iteration. 

(b) It assesses the degree to which the iteration has achieved its 
objectives and satisfied its evaluation criteria. 

(c) It reviews the iteration and test results. And on the basis of 
these results, amount of required rework is determined, and the impact of 
iteration results on the plan for subsequent iterations is also reviewed. 


0.40. What is periodic status assessment and its advantages ? 


‘Ans, Periodic status assessment checkpoints are the management 
reviews that are conducted at regular intervals like monthly or quarterly 
during the project development so as to address the project progress and to 
identify its quality. In short, such an assessment provides project snapshots. 
This is useful so as to ensure continuous attention over project dynamics 
and maintain open communications among the various stakeholders: Status 
assessments are necessary for forcing the management to focus or a 
quality and progress of the project. Status assessments are also used or 
making project-to-project comparisons, and distributing best practices within 
the organization. 


Advantages — The advantages of periodic stat 
follows — i 
- essing 
(i) Status assessments provide a mechanism for oe ae 
and communicating to stakeholders, resolving management and techn’ 
and also resolving project risks. 
(ii) Status assessments can derive the objectiv! 
on-going activities and from the evolving product con 


us assessment are as 


e data directly from 
figurations. Status 
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assessments provide a mechanism for propagating the project Progress, its | 
quality trends, practices, and experience information among all the Stakeholders | 
in an open address forum. ;w 

(iii) Status assessments are necessary for forcing the 
to focus on the quality and progress of the project and its dynamic 


MANAGEMENT 


SOFTWARE 
oe DISCIPUNES 


_ITERATIVE PROCESS PLANNING, PRO 


IES, PROCESS AUTOMATI 


ON, 
TON, 


Q.1. Explain iteration planning process. 


Ans. Planning defines the actual sequence of intermediate results. It 
involves the content and schedule of the major milestones and Ûr poppi 
iterations is probably the most tangible form of the evel risk peran 
plan. An evolutionary build plan is necessary because it ELON al ie e 
build content and schedule as early conjecture evolves into well-un . 
Project circumstances, Iteration allows complete oe a = 
Project along with the global assessment of entire project baseline. 


i ; : ed en route to 
1teration, such as monthly, weekly or daily builds are perform 
these project level synchronization points. 


andidate 
(i) Inception Iterations — The foundation #vpoyenia ot a give an 
architecture are integrated by the early prototyping ê ee 
executable framework for elaborating the difficult use cases 0 j çirayê 
have the existing components, commercial components and ao E 
Sufficient to demonstrate a candidate architecture and garigien: i oftware 

Understanding to establish a credible business case, vision and s 
velopment plan, A 

? n result in é 
archit 1) Elaboration Iterations — Elaboration S r 
Seture that includes complete framework that is require ses should 
e demo, O Pletion of architecture iteration, few difficult use ca 
Strable with the following tasks — 
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(a) Initializing the architecture. l | 
(b) Injecting a scenario to drive the worst-caseflataprocessing i 
f 


flow through the system. 
(c) Injecting a scenario to drive the worst-case control flow 
| 


through the system. 
(iii) Construction Iterations — Number of projects need atleast two | 


construction iteration as follows — | 
(a) An alpha release would include executable capability for all | 


the difficult use cases. 
(b) A beta release typically gives 95% of the total product 
| 


capability breadth and achieves some of the important quality attributes. 


(iv) Transition Iterations — Most projects employ single iteration to 
transition a beta release into the final product. A typical project may have | 


following six iteration as follows — 
(a) Inception iteration — 
(1) Architecture prototype 
(b) Elaboration iteration — 
(1) Architecture prototype 
(2) Architecture baseline 
(c) Construction iteration — 
(1)Alpha release 
(2) Beta release 
(d) Transition iteration — 
(1) Product release, 
A project that involves many stakeholders uses one additional inception 
iteration and two additional iterations in construction to achieve a total of ninê 
iterations, 
9.2. What is the purpose of work breakdown structures (WBS) ? 
Ans. A good work breakdown structure (WBS) and its synchronized 
management with the process framework are necessary for the success of 
software project development, A good WBS is developed based zp fx 


J ê 
Hee re dela such as — way of Conducting project management, CU ” f 
Dy in the organization, expectations of customers, and econo” 


sing 


flow 


st two 


for all 


roduct 
s. 


tion to 
y have 


Software Managemen 
constraints. A WBS decomposes the project plan in 


tasks. And various factors that lead to such decomposition are 
components, functions, organizational units, life-cycle phases. 
A WBS generally consists of following information structure — 


(i) Explanations about all major works, 
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to various unique work 


product 


(ii) Clear decomposition of task responsibilities, 


(iii) Framework for scheduling, budgeting, and tracking the 
expenditures. 


0.3. Give major features of work breakdown structures, 


Ans. The major features of work breakdown structures are as follows — 
() Structure - 


(a) WBS diagram is drawn like the organization chart. 


(b) Different desktop application offer functionalities to easily 
Create this kind of diagrams. 


(ii) Description - 


(a) Each WBS element should be described with a title. 


(b) The meaning of each title should be clear. 
(iii) Coding - 


(a) One of the main feature of WBS is the ability to uniquely 
Code the different elements of the work. 


ai 
4 


(b) The coding system can be alphabetic, numeric or alphanumeric. 
(iv) Depth — 


levelg (a) The recommended depth of a WBS diagram is three to four 


> ject 
Presented į (b) Each Project manager could then have his/her projec 
NÛ 1® one diagram, 


N e : jagram is 
'o make 4” Level of Detail — A rule of thumb in creating a WBS # saê 
Work the West level element small enough to be considered a seq 

3 hen estimating the amount of work in a project. 


€ down uses of work breakdown structure. 


Haa of work breakdown structure are as follows ~ 
Buca ucla 


“dividing the project into phases. 


82 Project Management 


(ii) For dividing the project into responsibility areas within the 
organization, 


(iii) For dividing the schedule of the project into sub-schedules whose | 
interrelations are known. f 


(iv) For giving grounds to following the cost ofthe project by defining 
clear targets to it. 


(v) For giving hierachical outlining and coding for the work to be 
done. 


Q.5. List out the conventional work breakdown Structure issues. 


Ans. The conventional work breakdown structure has three major 
drawbacks as follows — 


(i) Conventional WBS are prematurely structured around the 
product design. 


(ii) Conventional WBS is planned so as to define the budget either 
in detail or in brief. It is generally observed that, large software projects are 
over planned and small software projects are under planned. But the basic 


5 a + n n c f t 
problem with over planning i.e., planning in too detail is that these details do | 
not grow accordingly with the level of reliability. 
oe 3 3 i 
(ii) Conventional WBS are project-specific and fails to incorporate = 
cross-project comparisons. There is no standard WBS structure define and el 


therefore, it becomes difficult to include comparisons of different plans, budget, 


schedules, various organizational efficiencies and their cost trends, productivity 
trends, and quality trends across various projects. 


0.6. Explain evolutionary work breakdown structure. 


Ans. Evolutionary WBS must organize the planning elements around the 
process framework rather than the product Sramework. This approach better 
accommodates the expected changes in the evolving plan and allows the level 
of planning fidelity to evolve in a straightforward way. Thus WBS organizes 
the planning elements in the following levels of hierarchy — 

Level 1 — This level elements are define 


d in various workflows such as 
the management, environment, requirements, design, implementation, 
assessment (evaluation), 


and deployment workflows. 
Level 2 — This level elements are defined in all the four phases of the Be 


cycle i.e., the inception, elaboration, Construction, and transition phases- 
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Level 3 -- This level elements are defined i 


the artifacts of each phase. These elements m: 
hierarchy that collects the cost of a discrete artifacts for a giv. 

: e 
they may be decomposed further into several lower level Sêvo a or 
together, produce a single artifact. A WBS that i at, taken 


çe a s Consistent with the wo 
phases and activities of the process framework. cong 


Nall the activities that derive 
ay be the lowest level in the 


This structure describes how the elements of a process framework are 
integrated into a project plan. It needs to be tailored to the specifics of a 
project in many ways are as follows — 


(i) Scale — Bigger projects have more levels of hierarchy and 
substructures. 


(ii) Organizational Structure — Software projects that comprise of 
subcontractors or multiple organizational entities introduce few constraints 
that are helpful in various WBS allocations. 


(iii) Level of Custom Development - Focus varies upon the 


requirements, design, and implementation workflows as per the features of 
the project. 


(iv) Business Context — There may be few commercial software 
products that are delivered to a broader category of customers. Such projects 


require much more detail description of the substructures for their deployment 
element. 


3 ject 
(v) Previous Experiences — Very rarely, it happens that a ke 
needs to be started from scratch i.e., from a clean slate. Else, most 0 


, : ; j 
projects are developed as new versions of legacy systems with an improve 
WBS 


at 
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A good WBS provides an insight into important features, function priorities 
and overall structure of the project plan as shown in fig. 3.1. 


Also, a WBS provides a reliability of planning elements ranging right from 
rough planning packages (such as rough budget estimation) to fully planned 
activities (well-defined budget and continuous assessment of actual versus 
planned budget). 


Q.7. What is planning guidelines ? 


Ans. Software developing organization work on a wider range of 
application domains. It is risky to make specific project plans independent of 
project context but it is valuable. Therefore, to avoid these risk, two simple 
planning guidelines should be adopted for developing a good project plan. 
These guidelines are as follows — 

(i) Default web budgeting — roughly, allocate costs for the first 
level WBS elements. 
(ii) Allocate the efforts and schedule across the life-cycle phases. 


Q.8. What are the various strategies of design ? Which is most popular 
and practical ? (R.GP.K, June 2005) 
ya 
Differentiate between top-down and bottom-up design. 
(R.GP.V., June 2008) 


Ans. A system is actually consisting of components, having components 
of their own. In other words, a system is a hierarchy of components. The 
highest-level component corresponds to the total system. Such a hierarchy 
can be designed by two possible approaches i.e., top-down and bottom-up. 
The former one starts from the highest-level and moves towards the lower 
level of the hierarchy, while in contrast, the latter starts with the lowest-level 
component and proceeds through progressively higher-levels to the top-level 
component of the hierarchy, 

A top-down approach starts by identifying and decomposing the major 
system components into their lower-level components, This process repeats 
until the desired level of detail is achieved. Top-down design strategies often 
result in some form of stepwise refinement, which is the process in which 
starting from an abstract design, in each step the design is refined to a better 
level, until reaching the level where no more refinement is needed and e 
design can directly be implemented. The top-down approach has been fou" 
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to be extremely useful for design. Most of the methodologies are based on this 
approach. 


A bottom-up approach of design starts with designing the most primitive 
components and proceeds to higher-level components using lower-level 
components. This method works with layers of abstraction. Beginning from 
the very bottom, operations providing a layer of abstraction are implemented. 
The operations of this layer are then implemented in more powerful operations 
and a still higher layer of abstraction, until the stage comes where the operations 
supported by the layer are the desired ones. 


A top-down approach is appropriate in case where the specifications of 
the system are clearly known. However, if a system is to be built from an 
existing system, a bottom-up approach is more appropriate. 

Pure top-down or pure bottom-up approach is often not practical. For 
being successful using a bottom-up approach, we must have a good notion of 
the top towards which design should be proceeding. Unless having a good 
idea about the needed operations at the higher layers, it would be difficult to 
determine what operations the current layer should support. On the other 
hand, top-down approaches require some idea concerning the feasibility of 
the components specified during design. Also, these components should be 
implementable which needs some idea concerning the feasibility of the lower- 
level parts of a component. An approach combining the two (i.e., fop-dewn 
and bottom-up) approaches is providing layer of abstraction for the application 
domain via., libraries of function having the functions of interest to the 


1 
| 
z application domain. î 
: 0.9. What is the need of pragmatic planning ? 
J | i os (i). Performing the iterations becomes easy if a plan is ready. While 
el fe eig an iteration ‘n’ of any phase, the software project menager 
e | TRA aly monitors and controls against the plan that was initiated in 
| ion “n - 1? and the planning iteration ‘n + 1’. 
gi | current a DA good project management is an art of making trade-offs in the 
n ereke i s 
ats | iterations, e next iteration plans based on the results of current and previow 
en Ay 
ject i i anning. 
ch That means, r of every project is achieved only by good pon 
tef inadequate rom poor architectures and misunderstood requlTeme > 


Planning i r project 
th? failures, £ is also one of the most common reasons for proj 


86 Project Management 


(iv) A project plan defines how the requirements will be late 
transformed into a product considering the business constraints. And this 
product will be realistic, understandable by the stakeholders, and easily usable. 


(v) Plans are not only useful for the project managers - As more 
open is the planning process and its results, more ownership will be attained 
among the team members. That means, bad and closed plans cause destruction 
and good open plans encourages the teamwork. 


0.10. Give a brief introduction of, ‘project organization and responsibilities. 


Ans. Organization is an important part in the software line-of-business as 
it fulfils the basic needs necessary to support the software development. 
Similarly, project organization is the large extend about the people involved in 
software development. Various different types of people come together and 
form a team for the project organization and these teams are responsible for 


the work allocated to them. In general, project organization binds some 
responsibilities to the team and allocate some us 


and all) task towards that team members. 
and small components also to complete w. 


eful or decorative (designing 
This ensures the large architecture 
hole project. 

9.11. What are the reasons for project failure ? 


Ans. The reasons for project failure are as follows — 
(i) 


Unclearly defined Software requirements 

(ii) Inability to track and report the project’s Progress status 

(iti) Unmanageable risks ^ 

(iv) Communication gap amo 

(v) Use of unsuitable and p 

(vi) Incapable to handle Project’s complexity 

(vii) Impractica} expectations 

viii) Inabili indivi 

A me meê individual and Personality conflicts 
(x) Lack of Project Management. 

0.12, Discuss briefly, defa, 


a ri ' 
nlne ries 2 Organization task which is completed 
Oe a. i A 
ition and maintenance. aake king on several tasks such 


aS process defin: 


4 
> 
` 
> 


various different roles to achieve success within the o 
tole of following leading activities such as leader, ma 
and professional working tasks. 
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Organization manager performs leadin g task in organization, He performs 


rganization, He plays the 
nagement administrative, 


Organization 
Manager 


Software 4 
Engineering 


Software Engineering, 


Project 
Definition 
and 
Improvement 


Compliance 
; Periodic Risk 

Assessment 
Os oS 


Project Review Authority 


Environment Project 
Authority Infrastructure Administration 
Engineering 
Process Skill Centres 
Automation. O ê Professional 


Development 


Fig. 3.2 Role of Software Line-of-business Organization 
The main features of the default organization are as follows — a 
(i) Responsibility for process definition and maintenance is specific 


silt ense. 
to a cohesive line of business, here process commonality makes sı 


Gi) An organizational role which is equal in importance to the ana 
ition is the Fesponsibility for process automation. Projects get process 
ity firstly via the environment support of common tools. G 
(ii) A single individual or several different teams can fulñl the 

ional roles depending on the scale of the organization. 


Duties of Organization Manager - 
are Several duties of an organization manager as listed below 
Make plang for various processes. 
fii) Build 


Organizational development strategy: 


ae 
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(iii) Give directions, advice and counseling to the staff who a 


working for the process. 


(iv) Contribute 1 
researching, analyzing, designing, coaching, providing rec 


n various tasks like monitoring, coordinating, — 
ommendation, 


managing overall and etc. 
(v) Play the role of ‘agent of change’ when required. 


(vi) Maintain various kinds of records. 


(vii) Support in data collection. 
The role of software line-of-business organization as shown in fig. 3.2. 


(i) Software Engineering Process Authority (SEPA) — The main 
task of software engineering process authority is to allow information exchange 
and provide project guidance for project practitioners. Organization general 
manager or any individual or a team representative performs the role of SEPA 
who keeps track of the process maturity and improvement in the future project 
process. The SEPA must help initiate and periodically assess project processes. 
If the SEPA understands both the desired improvement and the project context 


then catalyzi Ê SE 
E we i capture and dissemination of software best practices can 


and bein’ ed ê ea role in any organization. It takes on responsibility 
could be a Ke ce bees ieee! definition and its maintenance. The SEPA 
ene individual, the general manager, or even a team of 
gee LÊ e SEPA must truly be an authority, competent and powerful, 

p n rendered impotent by ineffective bureaucracy. 


Duties of SEPA — 3 
follows — ‘A — There are several duties of a SEPA which are as 


(a) Initiate process, 


b 3 
(b) Assess project or process in each milestone. 


(c) Responsi : 
duty involves ee deye an for process definition and maintenance - This 
project. mprovement and innovative tool insertion in the 


(i) Software 
performs the mang: € Engineering Environment Authority (SEEA) - Hê 


: major role since whatever i : 
SE EA can be targeted to ipapa r investment done on the single projec! 
Significant return on investment eşte return, For a common process, to gef 4 

SEBA role is essential. Only when someon’ 


> Senê ; 
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ion (the SEEA) is responsible for supporting and administering 

wa nt then tools, techniques, and training can be amortized 

„gandard Bee ticle projects. The environment may be augmented, 

eectvel ê Walk but the existence of an 80% default solution for each 

| Bê aen to patting institutionalization of the organization’s process 
anda good ROI on capital tool investments in different cases. 


inthe organ! 


Duties of SEEA - There are several duties of SEEA which are as follows — 


(a) Automate the organization process - main task 


bal 
(b) Maintain organization standard environment 
| (c) Train those people who are working on the project. | 
Ê (iii) Project Review Authority (PRA) - Project review authority is ka 


‘sponsible for project compliance with all organizational and business units. 


Heisalso responsible for meeting the requirements of a contract or some 
ther project compliance standard. The PRA reviews both the project’s 
nance to contractual obligations and the project’s organizational policy 
BALÎ - The customer monitors contract needs, contract milestones, 


i “cl deliverables, month] i i 
| ty ena y management reviews, risk, progress, cost, 


a 


y The PRA revi 
L Hinizanona] Reviews Customer commitments as well as adherence to 
f Mher tiske Policies, organizational deliverables, financial performance, and 
and accomplis ; 
4, hments. 
Pais of PR 
@ nag are several duties of PRA which are as follows — 
pad i ® 1ew customer commitment. 
iets Be devoted to ra an sw. SARÊ 
te, financial ganizational policies, organizational 
Nûjen taş, Performance, and other risks and accomplishments of 
his : te) Support 
= | a art other relevant teams. 
Aarla Clune — lı is a su; 


Rg D) Pport system for the human, researc 
rhs and 1 „ research 
WÎ the ing. other capital software engineering assets. 


are as follows — 
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(4) Rules and regulations 
(5) Legal information related to corporate world. 


(b) Engineering Skills Centred Infrastructure — 
(1) Tools warehouse and maintenance department 
(2) Proposal support system 
(3) Independent research and development. 

(c) Professional Development — 
(1) Organization of the departmental training camp 
(2) Hiring employees 
(3) Database maintenance skills 
(4) Maintaining the library including literacy 
(5) Publish technical support books. 


0.13. Write short note on Project organizations, 


Each team takes care of the software 
quality, they check each i 


~a 
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a are Development = j 

(iii) Softw P i Team - It makes relation between the 
components designing and its maintenance activity. 
| (iv) Software Assessment Team - It takes care of software 
| improvement. All the priorities finding done are cross-checked by the 
. qgsessment team. 


Customer Interface, 
PRA Interface, 
Planning, 
Monitoring, 

Risk Management, 
Software Project 
Development, 


Project Improves 


Status Assessments 


System Analysis/ 
Software Architect/ 
Requirement Reviewer/ 
Business Process Analyst/ 
Siw Model Reviewer/ 
Business Designer 


re Assessment 
Software Architecture Software Development PR Analyst/ / 
Test Designer/Tester/ Software Architect/ Designer/ LC 
lntegrator/ Configuration Database Designer/ Design Revers 
mager/ Architecture Design Reviewer/ Code Reviewer e 
er/ Design Reviewer/ Requirement Specifier/ Requirem S DR 
de Reviewer/ System User Interface Designer User intern me 
yey rader Technical Database 
*! Tool Specialist/ 
Course Developers/ 
elopment Manager/ 
hange Control Manager 


Fig. 3.3 Project Organization è 
ent team 
Q.14. Explain the tasks of software managem 


s carried 
„takeholders !* 
jons to all sta -act manage 
Ans. The bi nnn gc win conditions are projeet „of 
TURAN ete al oa For this the Ts he focus € 
nageme . igo: 
Spends every day worrying about balance. The ath jife-cyel® 
‘are management team activities over the proj 


shanges 
For planning the effort, adapting the plan v5 plan, man 
è needs or the design and conducting t kes owner 
*8Ponsible. Toward this end, the team të 
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management and project scope, and sets operational priorities adros 
project life-cycle. 


These activities correspond to managing the expectations of all sta 
throughout the project life-cycle at an abstract level. Ownership gi i oe j 
of quality is taken by the software management team. In particu a J 
responsible for attaining and maintaining a balance among these aspec 
that the overall solution is sufficient for all stakeholders and optimal for as 


many of them as possible. The software management team activities is shown 
in fig. 3.4. 


Financial Administration, 
Systems Engineering, 
Quality Assurance 


Vision, WBS, Personnel Assignments, 
Requirements Set, Plans, Priorities, 
Status, Assessments, Risk Management, 
Business Case, 


Project Control, Scope 
Definition, Stakeholder 
Satisfaction 


Software Development 
Plan 


Life-cycle Phases 


Team Formulation, Risk Resolution, 


r Transition Ph i i 
Elaboration Phase Construction Phase Planning, Risk reyen Satisfaction, 
planning, Contract Planning, Full MI Ee ic Contract Closure, 
x Ê Si ii Staff Reer uitment, Construction Plan Bales Support, 
osts Construction Costs Optimization nae paniatan 
anning 
3.4 Software Managem 
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group. Normally the software development team comprises Various sue ee 
dedicated to groups of components which need a common skill set. This skill 


set have the following — } 
(i) Graphical User Interfaces — These are special wida experience 

in the display organization, data presentation, and user interaction necessary | 

to support human input, output, and control require. | 
(ii) Commercial Components — These components vetelee with l 

detailed knowledge of commercial components central to a system’s architecture. | 


(iii) Database — Database are specialists with experience in the Û 
organization, storage, and retrieval of data. | 


(iv) Domain Applications - These are specialists with experience 
in the algorithms, application processing, or business rules specific to the 
system. i | 


(v) Operating Systems and Networking — These are specialists with | 
experience in the execution of multiple software objects on a network of | 
hardware resources, including all the typical control issues associated with l 
initialization, synchronization, resource sharing, name space management, i 
reconfiguration, termination and inter object communications. 


Component Teams 


Deployment Set, 


Component Design, : 
Implementation, Stand- Í 1 
alone Test, Maintenance, | 


Implementation Set 
Design Set 


Documentation t 
te 
Life- 
ife-cycle Phases r 
ac 
de 
! 5 > 
Prototyping a Ûlan l y 
Critical Com { 
u] ponent $ b 
rd viel Make/Buy Design, Critical euneuent Design, Component | ` 
mı en: , 

4 aes. i Implementation, anent u 
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Baseline est, Component 

Fi j Maintenance 
g. 3.6 Software Develo 


pment Team Activities 
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This team is responsible for the quality of individual com 


, 3 ` ponents, including 
all component development, testing, and maintenance, Component tests should 
be built as self-documented, repeatable software which is treated such as 
other operational component source code so that it is maintained naturally and 

| is available for automated regression testing. How any design or implementation 


issue local to a single component is resolved, it decides development team. 
The software development team activities is shown in fig. 3.6. 


0.17. Explain the tasks of software assessment team. 
| i 


Ans. The focus of software assessment team activities over the project 
| life cycle is shown in fig. 3.7. An independent team is used for software 
| assessment due to two reasons. The first has to do with ensuring an independent 
quality perspective. Generally this debated method has its advantages like 
| ensuring that the ownership biases developers do not pollute the assessment 
| 


of quality and disadvantages like relieving the software development team of 
| ownership in quality, to some extent. 


To exploit the concurrency of activities is the very important reason for 
using an independent test team. By'developing the software schedules can be 
accelerat and preparing for testing in parallel with development activities. Change 
management, test planning, and test scenario development can be performed in 
parallel with design and development. A modern method should employ use- 
| Case-oriented or capability-based testing organized as a sequence of builds and 
mechanized via two artifacts such as release specification and release description. 

i Every release may encompass many components, since integration is 

) Proceeding regularly. Evaluation criteria will document what the customer 
i may expect to see at a major milestone, and release descriptions will substantiate 
Se tent results, Generally, the final iteration(s) will be equivalent to acceptance 
‘esting and include levels of detail similar to the levels of detail of conventional 
ve test plans, procedures, and reports. Some component tes 


ts may 
in release 

: € elevated to evaluation criteria, with their results documented in rele as 

: Various com informal component testins 

e i Î on: ndergo only informa 

| | bythed ponents may underg y 


a ê re: st software 
| buittby ‘lopment team, with the results captured only within the test so Be, 
i 


. AT ad 
' feke Formal testing for many components will then be subsumec 


scriptions. All 
“evel evaluation criteria and corresponding release descriptions 
testing to y 


| x t 

are not created equal — Some of them deserve formal a 

à papa û 

esting, *rify needs, while others are best tested in the Taê i 3 Mr 
RO Judgement must be left to the discretion of the assessmer 


Ah AR 
ERAR e ee 
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The quality of baseline releases with respect to the needs and custome 
expectations is depend on assessment team. Therefore, the assessment 
team is responsible for exposing any quality issues which affect the 
customer’s expectations, whether or not these expectations are captured | 


in the requirements. The software assessment activities is shown in 
HERRI: 


Change Management, 
Deployment, Environment 
Support, Release Testing 


User Manual, 
Environment, Release 
Specifications, 
Deployment Set, 
Release Descriptions, 
Deployment Documents 
SCO Database 


Independent Testing, 
Project Infrastructure, 
Metrics Analysis, User 
Deployment, Change 
Management, Configuration 
Control, Requirements 
Verification 


Life-cycle Phases 


Primary Scenario Architecture Release _ Infrastructure 


A a ` Release Baselining, 
Prototyping, Testing, Change Upgrades, Release Change Management, 
Infrastructure Management, Testing, Change Requirements Veri- 
Planning Infrastructure a 


s Management, User 
Baseline, Manual Baseline, 
Initial User Manual Requirement 


Verification 


fication, Deployment 
to Users, Infrastructure 
Maintenance 


Fig. 3.7 Software Assessment Team Activities 


9.18. What are the key points of process automation ? Also define the 
three levels of process automation, 


Ans. The key points of process automation are as follows — 


(i) Envyironment—Th 
where the environment should. b 
is an artifact of the process, 


. . . jo" j 
ls is the prime element of process automat is jê 
© good and suitable for process growth. 
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i d 
iected also. So the proper change management is necessary. An 
imes rejecte j 
sometim 


ly changes are always rejected by the development department 
C 

that, costly Cheney 

| n project organization. 

leno 


j JB dêkê 


La nd Trip Engineering - Since the project development 
| Û cira the changes if it is expensive then in such cases, the 
department xe round trip engineering and its environment promotes the 
g: Sen ia This change also gives technically skilled work. 

freedom 0 : 


iv) Metric Automation - As the changes are done, controlling these 
h ça is very important. Metric automation provides the essential 
new chang | : 
| environment for effective project control. 


Ø) Role of External Stakeholders - They try to interact with 
| development team for the improvement at the ti 


lon in the Process is done at Project 
‘UPport at th 


© macro level is known as an 
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i j the 
0.19. What are the building block of process automation ? Exp\ain F 
with a neat diagram. 


Ans. There are lots of tools available that are employed to automate the 


software development process. Many software process development wed îyê sma 
use at least one tool. Each of the process workflows has a different requirement requ 
for automation support. The automation and tool components involved in gene 


process workflow is shown in fig. 3.9. 


(i) Management - Workflow is the process that contains small mode 
task links together. The automation in the tasks, resources and internal furthe 
operations of the process is called workflow automation. There are lot of it into 


opportunities for automating the project planning and control activities of 
the management workflow. For generating the planning artifacts, software 
cost estimation tools and WBS tools are useful. Workflow management 


tools and a software project control panel which can maintain an on-line 


version of the status assessment are advanta 
plan. 


Management 


iteratio 
compili 


geous for managing against a n 
requires 
test auto 
and docu 
important 
instrumen 
Tt is also 
Cycle. 


2.20. 
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| the system development group. Vision statement is accessible by the buyer 
| of the system. 


(iii) Requirement - The flow of the requirements finally reaches to 
smallest unit. System requirements decompose into subsystem, subsystem 
requirements are fulfilled by components while component requirements are 


generated by smallest unit. = 
(iv) Design — The targeted tool for the design workflow is visual ae 
modeling. Generally this model is used to capture the design models which are + 


further used to present it in human understandable format and finally translate 


it into source code. - 


(v) Implementation - This workflow is based on the productive 
iteration, which is based upon the programming environment include editing, 
_ compiling, debugging, linking, running, etc. 


î (vi) Assessment and Deployment — The assessment workflow 
4 Tequires all the tools just discussed as well as additional capabilities to support 
_ test automation and test management. To increase change freedom, testing 
_ 4nd document production must be mostly automated. Defect tracking is another 
Nant tool that supports assessment — It provides the change management 
ntation necessary to automate metrics and control release baselines. 
also needed to support the deployment workflow throughout the life- 


The progress toward project goals and the quality of wak aj 
must be measurable throughout the software development cyc e 
*s Provide an important perspective for managing the pop 
“8 provide another. The most useful metrics are extracted diree i u 
ing artifacts, Objectives analysis and automated data Coe a 
o the Success of any metrics program. Subjective assessme 
techniques are likely to fail. 

“nd explain various core metrics. 
types of metrics may be of value in managin ; 
re seven core metrics that should be used on # 


ea a 
É are management indicators and four are qu 
are given in table 3.1. 


ng a modern 
software 
lity 
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Table 3.1 


Quality Indicator 


Breakage and modularity (average | Work and progress (work per- 
breakage per change over time). | formed Over time). 

Rework and adaptability (average Staffing and team dynamics 
rework per change over time) (personnel changes over time) 
Change traffic and stability (change | Budgeted cost and expenditures 
traffic over time) (cost incurted ‘over time) 

Mean time between failures (MTBF) 
and maturity (defect rate over time) 


The seven core metrics purpose and perspectives as shown in table 3.2. 


Table 3.2 


Seven Core Û 5 7 
- Purpose of Core Metrics | Core Metrics P. j 
A 


Plan vs. actuals, manage- | Function points, object 
ment indicator, iteration points, scenarios, test cases, 
planning. SCOs, SLOC. 


Budgeted cost | Plan vs. actuals, manage- | Full-time staff per month, 
and expenditu- | ment indicator, financial percentage of budget ex- 
res insight. pended, cost per month. 


Staffing and Hiring rate, resource plan | People per month added, 
team dynamics | vs. actuals, attrition rate. | people per month leaving 


Change traffic | Management indicator of | SCOs opened vs. SCOs clo- 
and stability schedule convergence, sed, by type (0, 1, 2, 3, 4), 
iteration planning. by release/component/sub- 
system. 
Reworked SLOC per change, 
by type (0, 1, 2, 3, 4), by re- 
lease/component/subsystem. 
Software rework, quality | Average hours per change, 
indicator, convergence. | by type (0, 1, 2, 3, 4), by 1°- 
lease/component/subsyste™. 
Failure counts, test hours 
until failure, by release/ 
component/subsystem. 
nd field | 
- Their 


Management Indicator 


Software scrap, quality 
indicator, convergence. 


Breakage and 
modularity 


Rework and 
adaptability 


Quality Indicator 


Test coverage or adequ- 
acy, robustness for use, 
quality indicator, 


MTBF and 
maturity 


These seven core metrics are depend on common sense 4 
i 1. 
experience with both successful and unsuccessful metrics progran 


Management Indicator 


fo 
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attributes have the following — 


(i) Their collection can be automated and nonintrusive. 


Û simple, objective, easy to collect, easy to interpret, 
and hard to misinterpret. 


| (iii) They give for consistent assessments throughout the life-cycle 
| andare derived from the evolving product baselines rather than from a subjective 
| assessment. 

| (iv) Their fidelity improves across the life-cycle. 


(v) They are useful to both management and engineering personnel 
| for communicating progress and quality in a consistent format. 


i 0.22. Explain the three management indicators metrics in detail. 
L i 


4ns. Technical progress, financial status, and staffing progress are the rs 
three fundamental sets of management metrics. Generally, management can 


assess whether a project is on budget and on schedule by examining these 
Perspectives, Financial status is very well understood; it always has been 
Most managers know their resource expenditures in terms of costs and schedule 


() Work and Progress — The number of activities of an iterative 
development pr 


: oject can be determined by defining a planned calculate of the 
Work in an obje 


: ctive measure, then tracking progress against that plan. Each 
major Organizational team 


Sy should have at least one main progress perspective 
lt is measured against. 


D i ; 
. Pefault perspectives of this metric should be as follows - 


® Software archi ives are use cases 
demonstrated, rehitecture team perspecti 


bag “Wêna (b) Software development team perspective are SLOC under 
ange Management, SCOs closed. 
test hours a Software assessment team perspectives are SCOs opened, 
“uted, evaluation criteria met. 


ple (o) Software management team perspective are milestones 
“ted, nag persp 


oye DB U. î 
Aze uated Cost and Expenditures — Measuring cost popen: 
compa Wte objec alwa i intai nagement control. 
“Oompa pate Objective ay ys essential to maintain manag 


i dt 
Cost essment of technical progress can be performed to 


expenditures through the judicial use of the metrics for 
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financial Progress takes on an 
ted value system is one common 


(a) Expenditure Plan - This i i 
; = s the planned spending profile 
for a project over its planned schedule, Generally this profile tracks the staffing 
profile for most software projects. 


(b) Actual Progress - This is the technical accomplishment 
salahe to the planned progress underlying the spending profile. In a healthy 
project, the actual progress tracks planned progress closely. 

(c) Actual cost — This is the actual spending profile for a project 
over its actual schedule. In a healthy project, this profile tracks the planned 
profile closely. 

(d) Earned Value — This is the value which shows the planned 
cost of the actual progress. 

(e) Cost Variance — This is the difference between the actual 
cost and the earned value. Positive values correspond to over-budget conditions; 
negative values correspond to under-budget conditions. 


(f) Schedule Variance — This is the difference among the 
values correspond to behind- 


planned cost and the earned value. Positive an 


schedule conditions; negative values correspond to ahead-of-sche 
conditions. 
(iii) Staffing and Team Dynamics- An iterative deve 
start with a small team until the risks in the requirements ‘and ar 
been suitably resolved. Depending on the overlap of ln a a Ae 
specific circumstances, staffing can vary. For disere ê posta 
development efforts (like building a corporate information sy: Hê inte | 
Aw e to expect Jopmen” Û 


lopment should 
chitecture poa 
d other projê” 


profile in fig. 3.10 would be typical. It is reasonabl ae tte 
team to be smaller than the development team for thes çen 
For a commercial product development, the E e ada sy e | 
development teams may be the same. When long-live ` i Û aoad ae | 
: i ig just continue 
Lı nwê are involved, maintenance 1s Jus 
products are inv 


and better releases. 


es, 


j 
j 


PA 
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Elaboration 


Effort —5% Effort — 20% Eff 
_ 10° hedule — 30° Mort — 65% 
Schedule—10% Schedule - 30% Schedute = 59% Effort — 19% 
Schedule — 10% 


Ewanê 
Staffing 


Project Schedule 
Fig. 3.10 Typical Staffing Profile 
0.23. Define the term life-cycle expectation. 


î Ans. There is no formal or mathematical derivation for using the seven 
û core metrics. But there were particular reasons for choosing them — 

(i) The quality indicators are derived from the evolving product 
>d rather than from the artifacts. 

(ii) They give insight into the waste generated by the process. 
gal (iii) In most manufacturing processes, scrap and rework metrics 
ns; 4re a standard measurement perspective. eee 

(iv) They recognize the inherently dynamic nature a an = 

the development process, Rather than focus on the value, they explicitly concentrate 
jod- on the trends or changes with respect to time. Û ava 
ule (v) The combination of insight from the current value and the € 

gives tangible indicators for management action. 

povl Qa, Write short note on process discrimination. i fo 
e nav’ Ans, There are two different dimensions of the an sen 
roj? 3 (i) Technical dimensions (ii) Managemen! arana to higher 
a g Both of these dimensions can be measured from Lae between 
Sc dewe: a Variability. Following table describes the gen is, indirect! ` 
a leseriy. 1 higher technical/management complex!» ion has lew 
pn pð technical factors which decide that whether anager eee 
pe ed Tig ee complexity or higher = Pune? And the hig 
oP ew Atha and lower technical complexity deseri nn 
p of a management complexity describe in ta 
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Table 3.3 


S.No.| Higher Technical Complexity 


Embedded, real time, distributed, | Clear-cut automation 
fault tolerant 


Lower Technical Complexity 


High performance Interactive performance 


Portable and hence might be 
multiple platform 


Single platform 


Unprecedented Many precedent system 


Architectural re-engineering Application re-engineering 


Table 3.4 


Higher Management 
Complexity 


Lower Management 
Complexity 


High scale - More number of 
peoples work in the team 


Large stakeholders 
The final output is “Project” 


Low scale — Limited peoples 
(smaller team) works in the team 
Limited stakeholders 


The final output is “Product” 


The average software project which is neither lower nor higher contains 
following attributes — 


G) Project development team contains 5 to 12 members 


(ii) Completion time of project is about for 10-12 months 
(iii) External interfaces range from 5-6 


(iv) Existence of few minor risks, 


y 


Wing 
Neterg 


such as 
nd Step 


tervals 
osed to 
beyond 


lysis of 01 A TION LAYER, 
3538 


R 1x1 „ê 


wa, Write short note on convolutional neural network. 


| Ans. A convolutional neural network (CNN, or ConvNet) is a class of 
deep neural networks, most commonly applied to analyzing visual imagery. 
| CNNS use a variation of multila 


yer perceptrons designed to require 


minimal preprocessing. They are also known as shift invariant or space invariant s 
oi 
ha 


artificial neural networks (SIANN), based on their shared-weights architecture 
and translation invariance characteristics. 

Convolutional networks wı 
Connectivity pattern between nı 
visual Cortex. Individual cortic 
region of the visual field kno 

| ent neurons partially o 
| 4 CNNs use relative] 


ere inspired by biological processes in that the 
eurons resembles the organization of the animal ‘ 
al neurons respond to stimuli only in a restricted NI. 
wn as the receptive field. The receptive fields of 
verlap such that they cover the entire visual field. 
y little pre-processing compared to other image 
traditional jı. algorithms. This means that the network learns the filters that in 
- ad were hand-engineered. This independence from prior 
uman effort in feature design is a major advantage. 


Stems, e applications in image and video recognition, recommender 
i medical image analysis, and natural language 


Processing ge Classifications, 

Output lac RA Conyolutional neural network consists of an input and an 

1picalıy, „2$ Well as multi ; j 

şu û consist of on multiple hidden layers. The hidden layers of a CNN 

Pooling layers, fully „ tutional layers, RELU layer, i.e., activation function, 
Description i Alaa layers and normalization layers. 

“OV ention Mathe r Process as a convolution in neural networks is by 


Cally jt; n 3 
ally it is 4 cross-correlation rather than a convolution 
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(although cross-correlation is a rel 
for the indices in the matrix 


ated operation). 
„and thus which weights 

Convolutional -- Convolutional layers a 
the input, passing the result to the next la 
tesponse of an individual neuron to visual 


This only has Significance 
are placed at which index, 
pply a convolution Operation to 
yer. The convolution emulates the 
stimuli. 

Each convolutional neuron processes data only for its receptive field. 
Although fully connected feedforward neural networks can be used to learn 
features as well as classify data, it is not practical to ap 


ply this architecture to 
images. A very high number of neurons would be necessary, even in a shallow 


(opposite of deep) architecture, due to the very large input sizes associated 
with images, where each pixel is a relevant variable. For instance, a fully 
connected layer for a (small) image of size 100 x 100 has 16000 weights for 
each neuron in the second layer. The convolution operation brings a solution 
to this problem as it reduces the number of free parameters, allowing the network 
to be deeper with fewer parameters. For instance, regardless of image size, 
tiling regions of size 5 x 5, each with the same shared weights, requires only 
25 learnable parameters. In this way, it resolves the vanishing or exploding 
gradients problem in training traditional multi-layer neural networks with many 
layers by using back propagation. 
Pooling — Convolutional networks may include local or global ponme 
layers. Pooling layers reduce the dimensions of the data by Çere henin the 
outputs of neuron clusters at one layer into a smgle neuron in a Jev lA 
Local pooling combines small clusters, typically 2 x 2. Global poo ing ac ap 
all the neurons of the convolutional layer. In addition, pooling may a e 
max or an average. Max pooling uses the maximum value uzr eac SR 
cluster of neurons at the prior layer. Average pooling uses the average va 
from each of a cluster of neurons at the prior layer. . 
Fully Connected -- Fully connected layers ganrect Sey pouon ba 
layer to every neuron in another layer. It is in principle the same as the a 
i LP). The flattened matrix goes throug 
multilayer perceptron neural network (M 
a fully connected layer to classify the images. Enea 
Receptive Field — In neural networks, each neuron Vigan ae 
some number of locations in the previous layer. In a fully o yA nelê sl 
each neuron receives input from every element of the RENON LR di 
convolutional layer, neurons receive input from only `: m o 5). 
the previous layer. Typically the subarea is ofa suas ê Ae : duy sonnected 
The input area of a neuron is called its receptive fie! à ke AEAT layet. 
layer, the receptive field is the entire previous layer. `. ` ; 
the receptive area is smaller than the entire previous layer. seit vast 
Weights — Each neuron in a neural network kê N a OWP çedîëld jn 
wee Se jma cy Leos We fod th input values is specifie 
the previous layer. The function that is applied to the inp 


eo ee ee ee ee 


in a neural 
i a bia ically real number). Learning Ir 
;ghts and a bias (typica ER 
ea by making incremental adjustments to jenê a 
Şinê ae of weights and the bias are called a filter an spr is n 
ae * ; = Û. input (e.gù., a particular shape). A distinguishing a U e 
ê Ha many neurons share the same filter. This reduces Lied A 7 
n le bias and a single vector of weights is used across all re pti 
nehe sanî ick tive field having its own bias 
fields sharing that filter, rather than each recep 


and vector of weights. 


bya vector 0 


Explain the following terms — 
(i) Filter size (ii) Depth (iii) Padding (iv) Stride. l : 
Ans. The hyperparameters of a convolutional layer are its spatial filter 
size, depth, padding and stride. They have to be chosen carefully in order to 
generate a desired output. 


(i) Filter Size — The filter size corresponds to the spatial extent (width 
and height) of the filters that are convolved with the input image at different 
spatial locations. Generally, the filters are quadratic, i.e. have the same width 
and height, and all filters of a particular convolutional layer have the same 
filter size. The filter size is heavily dependent on the spatial extent of the input 
images themselves, and we generally see larger filters for larger input images. 
In recent publications, however, the trend is to replace larger filters with a 


series of small filters, which is motivated by areduction of learnable parameters 
and substantial speed improvements. 


J 


(ii) Depth - The depth of the output volume controls the number of 
learnable filters that connect to the same region of the input volume. All of 


Py ness will learn to activate for different features of the input. For example 

ı1 the first convolutional layer takes the raw image as input. i t 
„ th 

filters along the depth dimension 5 p Tt 


1 may activate in the presence o 1 
oriented edges, or blobs of color, û 2o 


for instance. 
; (iii) Padding - The 
size of th 
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9.3. Define the term sub-sq 


mpling |, 
Ans, Sas 


ze of the down samplin v 
8 mask. For exam 
aa x 2 down sampling kernel is used, then each output dimension will 2 a 9 
î the Îran û Input dimension for all the images. This operation can be bı 
ormulated as — 
fui 
xj = down(x}) 
where down (-) represents a sub-sampling function. 
Two types of operations are mostly performed in this layer. Average pooling 
or max-pooling. In the case of the average pooling approach, the function 
usually sums up over N x N patches of the feature maps from the previous 
layer and selects the average value. On the other hand, in the case of max Whe: 
pooling, the highest value is selected from the N x N patches of the feature Corre 
maps. Therefore, the output map dimensions are reduced by n times. In a 2 
a n. ; y 
special cases, each output map is multiplied with a fem Some ae o 
sub-sampling layers have been proposed, such as fractional max-po n 
and sub-sampling with convolution. yolum 
Explain in detail about the convolution layer. m S be 
oes A lution € 
i is the core building block of a convo w S 
Ans. The convolutional abe i nê limitations of fully connected layers by fae o 
twork and aims to resolve l Pee cas ê. 
peur i mptions about the input data. The layer’s pal field, "eres 
making geometric assu ani rs or kernels, which have a small receptive din hetwo 
consist of a set of learnable filte: f the input volume. The architecture oe Perio ù 
but extend through the full vias i nal networks in general — is loosely 2 ic, 
Jutional layers — or con UC. he mammalian brain’s visual corî?” 
copy ngement of cells in the m: 
on the complex arra 
Da 
Brgy. in 
ha. ê 
Sê, 


cpa tye 
Convoluuon di 
d Output of a 


(a) 3D 
Fig. 3.1 Input, Filter an 
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; forward pass, the learnable filters are convolved with the — 
m behind the discrete convolution operation is to slide a 
e : : : 
eee the input volume at different overlapping spatial locations as in 
iter 


j 4-1) (4) (£) 
19 = x6 +wO +n! 
u,v 


j 0 - ~ SN (e Ae 
where x represents the current layer’s output for a given filter f, x the 


output of the previous layer, and the spatial extent of the filter in horizontal 
and vertical direction is given by u and y. 


During the backward pass, we calculate the partial derivatives of the loss 
function with respect to the weights and biases of the respective layer as in 


Vwi) L 2 (vos) k *wî?)) Pe 
u,v 


uv 


iG) Jan (vo) 
u,v 


^ uv 
Where, w denotes a s 


i patially flipped filter in order to compute th - 
Correlation rather than a convolution, ù seek 


- - What do You mean by pooling layer ? Explain. 

ns. Ê 

isa Tirê E li Se it concept of convolutional 
-unear 5 ê 

Woe Ownsampling. Th 

aes into a set of non-overlappin eae 
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where u and v denote the spatial extent of the 
width and height. 


Since the pooling layer does not have an 
backward pass is merely an upsampling operatio 
In case of the max-pooling operation, it is com 
the index of the maximum activation so that the 
its origin during back propagation. 

The hyperparameters of the pooling layer are its stride and 
they have to be chosen in accordance to each other, they can 
the amount of downsampling to be performed. 


non- . 
Overlapping Tegiong ; 
A In 


y learnable Parameters 

n of the upstream derivat the 
mon practice to keep ee 
gradient can be routed towards 


filter size. Since 
be interpreted as 


Q.6. What is fully connected layer ? Discuss its limitation. 


Ans. The fully connected layer is a synonym often used in the convolutional _ 


network literature and is equivalent to a hidden layer in a regular artificial network 
It is sometimes referred to as linear or affine layer. Intuitively, the fully connected 
layer is responsible forthe high-level reasoning in a convolutional neural network 
and is therefore typically inserted after the convolutional layers. The neurons | 
have full connections to all activations in the previous layer, as seen in a regular | 
artificial neural network as shown in fig. 3.3. | 

f 


Layer 
Layer Hidden X 
Layer 
(a) One Hidden Layer 
nm mm. nes x q 


Pun Layer k 
pwo 
_ (hì Two Hidden Layers. „ral Ne 


f 


———— 


tutional 


network. | 
onnected | 


| network 


. neurons | 


a regular 
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ly connected layer can be computed with adot product 
vious layer activations followed by a bias offset as in 


x = wt ED ea) 


The activations ofa ful 
ofthe weights with the pre 
i (NO 
(f-1) genotes the activations of the previous layer and x` ^, w Û Hin 
Ye nee the activations, weights and biases of the current layer, respectively. 
el e | 

b During the backward pass, the gradient with respect to the weights and 

biases are computed as in 


WOL = KOT (VD L) 


n 
Vol = VV, ^.) 
i-l 


where Y (e) denotes the upstream derivatives. 


The only hyperparameter in a fully connected layer is the number of output 


neurons the input connects to, i.e. how many learnable parameters connect the - 
input to the output. 
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_ 9.8-Explain the term dense layer, 
Ans. The dense layer use 

of connections between i 
units ofa dense layer are 
units in neighbourin 


s the linear set 
nput and output, All 
i fully connected to all 
r 8 layers in such a wa 

the units take every output from all units Wn 
former dense layer as their input and pass their 
Output to all units in the following layer. 


This leads to a very simple matrix-vector- 
computation, but it also leads to a very large 
set of trainable parameters. A neural network 
that consists of dense layers can be very 
successful for low dimensional data, but 
computation can become very expensive for 
high dimensional data like images. To handle 
such tasks, layers with weight sharing are 
introduced. 


Fig. 3.4 A Densely Connected 
Neural Net with Two Hidden 
Layers 


Q.9. Explain the term densely connected network (DenseNet). 


$ Gao, which 
setas D en the a of cock bee 
í the outputs y 
consists of densely connected ENN An block da it is forme 
connected with all successor ve ey it the name DenseN* 
ith dense connectivity between the layers rewarding i o duces network 
a. concept is efficient for feature reuse, which Dia anê Zê sition bloc’ 
A dense bloc ;agralll 
t consists of several al diag? 
e two adjacent dense blocks. The conceptu 
which are place 


of a dense block is shown in fig. 3.5. 


Ea 


the layo 
all the f 


where [ 
j—iarf 
consecu 
3x3 € 
operatio 
This nev 
network 


Q1 
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s as input. Fig, 3.5 illustrates 
equently, the Æ layer received 
Xo, a Xı-ı as input — 

By (HEX, Xo........ X,_1]) 


Each layer takes all the preceding feature map 
the layouts of resulting DenseNet schematically. Cons 
all the feature maps from previous layers of xo, Xj; 


) where [Xo; Xj, X2 -= Xj-ı1 are the concatenated features for layers 0, 
I-1 and H(-) is considered as a single tensor, It p 

consecutive operations. Batch-normalization (BN), followed by a ReLU and a 

3 x 3 convolution operation. In the transaction block, 1 x 1 convolutional + 

operations are performed with BN followed by a 2 x 2 average pooling layer. ro i 

This new model shows state-of-the-art accuracy with a reasonable number of 

network parameters for object recognitions tasks. 


cin , f 
erforms three different Tf 


Q.10. Explain the following CNN architecture — < + 
ed (i) LeNet (ii) AlexNet (iii) GoogLeNet. da 
4q 


Ans. (i) LeNet - Although LeNet was Proposed in the 1990s, limited 
computation capability and memory capacity made the algorithm difficult to 
implement until about 2010 however, proposed CNNs with the back propagation 
ich algorithm and experimented on handwritten digit dataset to achieve state-of- 
are the-art accuracy. The proposed CNN architecture is well-known as LeNet-5. 
ned The basic configuration of LeNet-5 is as follows (see fig. 3.6)— Two convolutions 
Net | (conv) layers, two sub-sampling layers, two fully connected layers, and an output 
otk | layer with the Gaussian connection. The total number of weights and multiply 
ke, Ê and accumulates (MACs) are 43 
ram As 


1 k and 2.3 M, respectively. 
becom tena hardware started improving in capability, CNNs stated 


and $ Popular as an effective learning approach in the computer vision 
ne learning communities. 


Input : 32x32 


Subsampling (16@5x5) 


| Convolution (6@28x28) 


Convolution (16@10x10) 


Layer#2 | Subsampling (6@14x14) 


“oF ig. 3.6 The Architecture of LeNet 
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(ii) AlexNet - Alex Krizhevesky proposed a deeper and wi der CNN; 
model compared to LeNet and won the most difficult ImageNet Challenge ` 
visual object recognition called the ImageNet Large Scale Visual Recognition 
Challenge (ILSVRC) in 2012. AlexNet achieved state-of-the-art re 'ognition 
accuracy against all the traditional machine learning and computer Vision 
approaches. It was a significant breakthrough in the field of machine learnin 
and computer vision for visual recognition and classification tasks and js the 
point in history where interest in deep learning increased rapidly. 


The architecture of AlexNet is shown in fig. 3.7. The first convolutional 

layer performs convolution and max-pooling with local response normalization 
(LRN) where 96 different receptive filters are used that are 11 x 11 in size. The 
max pooling operations are performed with 3 x 3 filters, with a stride size of 2, 
The same operations are performed in the second layer with 5 x 5 filters. 3 x3 
filters are used in the third, fourth, and fifth convolutional layers with 384, 384, 
and 296 feature maps respectively. Two fully connected (FC) layers are used 
with dropout followed by a Softmax layer at the end. Two networks with similar 
structure and the same number of feature maps are trained in parallel for this 
model. Two new concepts, local response normalization (LRN) and dropout, 
are introduced in this network. LRN can be applied in two different ways — First 
applying on single channel or feature maps, where an N x N patch is selected 
from the same feature map and normalized based on the neighbourhood values. 
Second, LRN can be applied across the channels or feature maps (neighbourhood 
along the third dimension but a single pixel or location). i 


: 
z 
: 


Conv. & ReLU 


Cony., MXP, LRN 
Cony. & ReLU 
Conv. & ReLU 


Layer 1:96 
Layer 2: 256 


RP 


Layer 4 : 384 
Layer 5 : 256 
Layer 7 : 4096 


Cte oe dn Ha 
Fig. 3.7 The Architecture of AlexNet Convolution, Max-poolins A 


Response Normalization (LRN) and Fully Connected (FO) La)” 


(iii) GoogLeNet — GoogLeNet was istian 5722 
Ê s l proposed by Chris xily 
in 2014.of. Google with the objective of reducing computation comple 


iF 
s 
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N red to the traditional CNN. This method was to incorporate inception 

or Sev hat had variable receptive fields, which were created by different kernel 

n we receptive fields created operations that captured sparse correlation 

r sizes. 

3 patterns in the new feature map stack. 

| 

WaN Filter 

1e Concatenation 

al 

n 

he 

2. 

23 | 

` 

Ê | Fig. 3.8 Inception Layer - Naive Version 

ar | ile ; : Û 

3 ) The initial concept of the inception layer can be seen in fig. 3.8. GoogLeNet : 

Dt | Improved state-of-the-art recognition accuracy using a stack of inception layers, $ 

rêt seen in fig. 3.9. The difference between the naive inception layer and final 

cu inception layer was the addition of 1x1 convolution kernels. These kernels 

fe allowed for dimensionality reduction before computationally expensive layers. 

Š d GoogLeNet consisted of 22 layers in total, which was far greater than any 
network before it. However, the number of network parameters GoogLeNet 
used was much lower than its predecessor AlexNet or VGG. GoogLeNet had 
7M network parameters when AlexNet had 60M and VGG-19 138M. The 
computations for GoogLeNet also were 1.53G MACs far lower than that of 
AlexNet or VGG. 
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Pig. 3.9 Inception Layer with Dimension Reduction 
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«Q11. Write short note on inception network, 


Ans. Inception network is often difficult to determine the best filter si 
NE : €T Sizes 
your network, and whether to use pooling layers. To overcome this incepti 
architectures use many different filter sizes and pooling layers in seal (a 
inception block), the outputs of which are concatenated and inputted to i 
next block. In this way the network chooses which filter sizes or combinations 
thereof to use. To solve the problem of a large increase in computational cost 
the inception networks utilize 1x1 convolutions to shrink the volume of the 
next layer. This network architecture was introduced by Szegedy to make a 
network deeper and wider, hence more powerful, but keeping the computational 
cost low. The inception network could thus go very deep and like Resnet, utilizes 
intermediate normalization layers to avoid vanishing and exploding gradients. 


0.12. Define the term input channels. 


Ans. In order to generate several inputs for the CNNs ensemble, we 
compute three input channel from the original RGB proposals. In total thee 
are four input channels, denoted by — x, € R4“W*P, for t e T= {RGB. GH, 
GM, LUV}, which correspond to RGB, normalized sum of gradient see 
for six orientations, gradient magnitude (computed from each channel inRG 3 
and LUV. Since, originally, the normalized sum of gradient histograms forsi 
orientations only has one channel in the third dimension, we replicate 
channel to obtain the remaining depth dimensions. 


3. What do you understand by transfer learning ? PARIA 
‘Ans. Transfer learning is an essential ingredient for apra em $ 
where knowledge learned in one domain for some task A aansit 
other domain for a different task. In the context of deep ae ott 
j commonly implemented by pre-trainıng a deep ne ae ined 
labeled dataset followed by pe p Th 
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| on a large dataset and then ine-tuning it on a differe i 
ets nt d 
result in higher accuracy and a faster training process ıı kav 3 oped to 
same CNNs from scratch, due to the shared features present in fe aie im 
į ayers. 
To demonstrate the power of transfer learning for classifying glitch yers 
compare the performance of the most popular CNN models for object Hê n we 
` namely Inception version 2 and 3, ResNet, and VGG. These CNNs were dial 
trained on a large dataset of images — i.e., ImageNet, which contains 1.2 gul 
labeled images of real-world objects belonging to 1000 categories over the course 


7es î : 
a of 2 to 3 weeks using multiple GPUs by other research groups. We obtained the = 
open-source weights from these models, and used them to initialize the CNNs 
Û before fine-tuning each model on the dataset of glitches. i ; 
“ea We show that transfer learnin g allows us to apply these powerful convolution ê 
a neural networks for classifying glitches using a very small training dataset of -& 
a Kenê obtain significantly higher accuracies, reduce the training time Oê 
ce y several orders of magnitude, and eliminate the need for optimizing hyper- sig 
| parameters. Furthermore, we show how information from multiple duration os 
onal spectrograms can be efficiently encoded into a single image in different color 
Ê | channels to enhance information provided to these CNN models. 
| ATA. Write short note on one shot learning. r 
| Ans. Neural networks classically contain a single data path from input to PR, 
e, we | output. This is because neural networks are often trained to perform a single > 
tbere | task; and this task does not change during the inference stage. If the task changes ; 
TEB | during inference the neural network would need to be retrained, in order to Rs 
Û ams perform the new task. Often it is not an option to retrain a neural network for i 
g B) | each new task, this is because there might be a lack of training data or the 
RG -’ | hardware used for inference is not powerful enough to perform SGD. This 
for ia | problem of having limited training data, or even only one example is also 
te this known as one shot learning. Tracking is in essence a one shot learning problem, 
as an algorithm is given one example of the target and asked to track this 
target over multiple frames. 
. eno” A more recent paper utilizes a neural turing machine to perform one shot 
ue ed t9 learning, the turing machine consists of a controller such as a feed forward 
T sfef network or a recurrent neural network that interacts with an external memory 
Zav module. This machine has long term storage in the network weights which are 
pe ‘puet slowly updated, and short term storage in the form of the aforementioned 
ov” gh external memory module. This structure achieved better results than a human 
"e, on a few shot problem using the dataset and was a big step forward compared 
s" a le Comparable methods at that time. The “matching networks for one shot 
to © pi” ee ne showed that, besides designing for one shot learning as in, training 
c) N a e aning can improve results even further. 
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h smaller space, resulting in dimensionality reduction. Unlike 
ae Sê et selection, which reduces the attribute set size by retaining a 
La ae set of attributes, PCA “combines” the essence of attributes 
ê an alternative, smaller set of variables. The initial data can then be 
Hemen onto this smaller set. PCA often reveals relationships that were not 


previously suspected and thereby allows interpretations that would not 
ordinarily result. 


PCA is computationally inexpensive, can be applied to ordered and 
unordered attributes and can handle sparse data and skewed data. 
Multidimensional data of more than two dimensions can be handled by reducing $ 
the problem to two dimensions. Principal components may be used as inputs 
to multiple regression and cluster analysis. In comparison with wavelet 


transforms, PCA tends to be better at handling sparse data, whereas wavelet nû 
transforms are more suitable for data of high dimensionality. 


. Explain the implementation of convolution neural network (CNN). 
Ans. The implementation of convolution neural network are as follows — 


popular library that can be leverage 


acyclic graph (DAG) that contains 

nodes, which represent mathematical operations, and edges, which encapsulate penn wa 
tensors (i.e., multidimensional data arrays). This computational graph offers a a A 
high-level of abstraction to represent the algebraic computation of the A^ Y 
constructed deep neural network models, independently of the programming A : 
language used, the execution environment, and the target hardware. Thus, it êy. 
provides TensorFlow users with the flexibility to execute their computation on 
one or more CPUs/GPUs, or even mobile devices. ù 

TF uses a concept known as deferred execution or lazy evaluation. This > 
means that there are two principal phases in a TensorFlow program — ae ; 

(a) A constructio 


i n phase, that assembles a graph, including 
variables and operations, 


pen-source high-level neural networks API, 
f running on top of TensorFlow and Theano. 
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Thus. Keras benefits from the advantages of both and provides 4 WE 
and more intuitive set of abstractions, which make it easy to configure neura 
networks, regardless of the back-end scientific computing library. The primary 
motivation behind Keras is to enable fast experimentation with deep neural 
networks and to go from idea to results as quickly as possible. The library 
consists of numerous implementations of neural network building blocks and 
tools to make working with image and text data easier. 


Keras offers two types of deep neural networks including sequence-based 


networks (where the inputs flow linearl 
y through the netw Ê 
based networks (where the inputs can skip çê Hye enê 


- certain la i +. êً 
more complex network architect ee yers). Thus, implementing i 


Al À as GoogLeNet an n `. E 
easy. However, Keras does not provide most AA an ene SqueezeNet Û i 


td 


eriod, those that must precede or 
follow other projects, those that support other projects or should be done in conjunction 
with them, those that can be outsourced, and other such special aspects of the projects. 

Next, screen out the weaker projects: Have costs on existing projects escalated beyond 
the project’s expected benefits? Has the benefit of a project lessened because the organi- 
zation’s goals have changed? Does a competitor’s new entry obviate the advantages of a 
project? Does a new (or old) project dominate an existing or proposed project in terms of 
its benefits, furtherance of organizational goals, reduced costs? Also, screen in any projects 
that do not require deliberation, such as projects mandated by regulations or laws, projects 
that are operating or competitive necessities, projects required for environmental or per- 
sonnel reasons, and so on. The fewer projects that need to be compared and analyzed, the 
easier the work of the council. 


Step 4: Assess Resource Availability 


Next, assess the availability of both internal and external resources, by type, department, 
and timing. Note that labor availability should be estimated conservatively, leaving time 
for vacations, personal needs, illness, holidays, and, most important, regular functional 
(nonproject) work. After allowing for all of these things that limit labor availability, add 
a bit more, perhaps 10 percent, to allow for the well-known fact that human beings need 
occasional short breaks to rest or meet other human needs. Timing is particularly impor- 
tant, since project resource needs by type typically vary up to 100 percent over the life cycle 
of projects. Needing a normally plentiful resource at the same moment it is fully utilized 
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elsewhere may doom an otherwise promising project. Eventually, the council will be trying 
to balance aggregate project resource needs over future periods with resource availabilities 
so timing is as important as the amount of maximum demand and availability. This is the 
major subject of Chapter 9. 


Step 5: Reduce the Project and Criteria Set 


In this step, multiple screens are employed to try to narrow down the number of competing 
projects. As noted earlier, the first screen is each project’s support of the organization’s 
goals. Other possible screens might be criteria such as the following: 


e Whether the required competence exists in the organization 

e Whether there is, or will be, a market for the offering 

e How profitable the offering is likely to be 

e How risky the project is 

e If there is a potential partner to help with the project 

e Ifthe right resources are available at the right times 

e If the project is a good technological/knowledge fit with the organization 

e If the project uses the organization’s strengths, or depends on its weaknesses 
e If the project is synergistic with other important projects 

e Ifthe project is dominated by another existing or proposed project 


e Ifthe project has slipped in its desirability since the last evaluation 


The result of this step may involve canceling some ongoing projects or replacing them 
with new, more promising projects. Beware, however, of the tendency to look more favor- 
ably upon new, untested concepts than on current projects experiencing the natural prob- 
lems and hurdles of any promising project. 


Step 6: Prioritize the Projects within Categories 


Apply the scores and criterion weights to rank the projects within each category. It is 
acceptable to hold some hard-to-measure criteria out for subjective evaluation, such as 
riskiness, or development of new knowledge. Subjective evaluations can be translated from 
verbal to numeric terms easily by the Delphi or other methods and used in the weighted 
factor scoring model. It should be remembered that criteria such as riskiness are usually 
composite measures of a set of “risks” in different areas. The same is true for criteria like 
“development of new knowledge.” 

It is also possible at this time for the council to summarize the “returns” from the pro- 
jects to the organization. However, this should be done by category, not for each project 
individually since different projects are offering different packages of benefits that are not 
comparable. For example, R&D projects will not have the expected monetary return of 
derivative projects; yet it would be foolish to eliminate them simply because they do not 
measure up on this (irrelevant, for this category) criterion. 


Step 7: Select the Projects to Be Funded 
and Held in Reserve 


The first task in this step is important: determining the most appropriate mix of pro- 
jects across the various categories and time periods. Ultimately, the organization’s strategy 
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drives the appropriate mix of projects. For example, a company that competes on the basis 
on being first to market with new products would expect to have a larger percentage of 
breakthrough projects while a company that competes in mature markets would likely have 
more derivative projects. 

Next, be sure to leave some percent (often 10-15 percent) of the organization’s 
resource capacity free for new opportunities, crises in existing projects, errors in estimates, 
and so on. Then allocate the categorized projects in rank order to the categories according 
to the mix desired. It is usually a good practice to include some speculative projects in each 
category to allow future options, knowledge improvement, additional experience in new 
areas, and such. 

Overall, the focus should be on committing to fewer projects but with sufficient fund- 
ing to allow project completion. Document why late projects were delayed and why some, 
if any, were defunded. One special type of delayed project mentioned earlier is some- 
times called an “out-plan” project (in contrast to the selected “in-plan” projects) (Englund 
et al., 1999). Out-plan projects are those that appear promising but are awaiting further 
investigation before a final decision is made about their funding, which could occur in the 
next PPM cycle or sooner, if they warrant the use of some of the 10-15 percent funding 
holdout. The result of this step (and most of the project portfolio process) is illustrated in 
Figure 5 in the Reading section. 


Step 8: Implement the Process 


The first task in this final step is to make the results of the portfolio analysis widely known, 
including the documented reasons for project cancellations, deferrals, selections, and non- 
selections as was mentioned earlier. Top management must now make their commitment to 
the PPM process totally clear by supporting the process and the results. This may require a 
PPM champion near the top of the organization. As project proposers come to understand 
the workings and importance of the PPM process, their proposals will more closely fit the 
profile of the kinds of projects the organization wishes to fund. As this happens, it is impor- 
tant to note that the council will have to concern itself with the reliability and accuracy of 
proposals competing for limited funds. 

Senior management must fully fund the selected projects. It is neither appropriate nor 
ethical for senior management to undermine PPM and the council as well as strategically 
important projects by playing a game of arbitrarily cutting X percent from project budgets. 
The council needs to be wary of interpersonal or interdepartmental competition entering 
the scene at this point also. In some organizations, individuals with their own particular 
agenda will ignore committees and processes until implementation time rolls around, and 
then they attempt to exercise their political power to undermine the results of others’ long 
labors. If this does occur, it is indicative of serious organizational problems and the PPM 
process will fail until the problems are corrected. 

Of course, the process will need to be repeated on a regular basis. The council should 
determine how often this should be, and, to some extent, it depends on the speed of change 
in the industry the organization is in. For some industries, quarterly analysis may be best 
while in slow-moving industries, yearly may be fine. Swanson (2011a) warns, however, 
that too-frequent reprioritizing of projects can result in confusion and frustration, particu- 
larly if resources suddenly are unavailable. 

Finally, the process should be flexible and improved continuously. Instinct may sug- 
gest ways that the process may be altered to better match the competitive environment, or 
to reflect more closely the organization’s goals. The process should be changed when it is 
found appropriate to do so, including categories, criteria, steps, the order of tasks, and so on. 

Before leaving the subject of project portfolios, it is important to consider the problem 
of decreasing the size of the organization’s investment in projects. The sharp economic 


downturn of 2008-2009 required a great many firms to do just that, and many were simply 
not prepared to handle the problem. Senior management, or the project council, should also 
develop a set of criteria for removing projects from the portfolio. In an interesting short 
paper, Wheatley (2009) notes that issues such as the size of the expected ROI may be of 
less importance than the timing of cash in- and outflows. The organization’s tolerance for 
risk is very likely to change during downturns. Some projects are luxuries. Others may be 
major drivers of future profits and growth. Some may be oriented to cost savings that could 
have almost immediate benefits. Even projects aimed at meeting legal mandates may have a 
cost that is significantly higher than the possible legal penalties if the mandates are ignored 
for a time. Many firms are choosing to pay the penalty instead of implementing costly 
federal mandates. Some projects can be stopped midway without doing much damage to 
the project’s expected success. Others cannot, and if delayed must start from scratch, or be 
cancelled. 

Developing a list of possible criteria for cutting or eliminating the funding for a project 
is complicated. To be useful, each item in the list should be prioritized. This is a job that 
demands close attention from senior management. 

A recent summary of PMI’s Thought Leadership Series concerning The Power of 
Portfolio Management (PMI, 2015) concluded with the following points: 


e Successful portfolio management requires effective communication and cooperation 
between those who formulate the strategy and those who execute it. 


Yet, survey respondents also reported that 20 percent of current projects should be 
terminated, 29 percent receive too few resources, and 19 percent receive too many. 

e Ata majority of firms, the degree to which C-suite executives follow their own inter- 
ests and pet projects undermines formal portfolio management. 


Portfolio management maturity correlates to firm success. 


Leading firms connect project execution to strategy fulfillment by aligning projects 
and programs to the strategy. 


Leading firms also seek simplicity, finding that the less complicated the approach to 
portfolio management, the more likely the firm can sustain its success. 


Leading firms create a portfolio-oriented culture and develop strong capabilities in 
portfolio management. 


In the next chapter we consider the selection of the appropriate manager for a project 
and what characteristics are most helpful for such a position. We also address the issue 
of the project manager’s special role, and the demands and responsibilities of this criti- 
cal position. 


Summary 
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This chapter initiated our discussion of the project management 
process by first describing organizational project management and 
the different roles and entities it encompasses. This included the 
initiation phase, the planning and execution of the project phase, 
and, finally, the benefit realization and routine use phases. Next, 
we described procedures for strategically evaluating and select- 
ing projects. We then outlined some criteria for project selection 
models and discussed the general nature of these models. The 
chapter described the types of models in use and their advantages 


and disadvantages. Considering the degree of uncertainty associ- 
ated with many projects, a section was devoted to evaluating the 
impact of risk and uncertainty. Concluding the discussion, some 
general comments were made about data requirements, the use of 
these models, and how to implement the project portfolio process. 
The following specific points were made in this chapter: 


e The role of projects in achieving the organization’s goals 
and strategy is critical. 
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e The eight-step project portfolio process is an effective way 
to select and manage projects that are tied to the organiza- 
tion’s goals. 


e Preparatory steps in using a model include (1) identify- 
ing the firm’s objectives; (2) weighting them relative to 
each other; and (3) determining the probable impacts of 
the project on the firm’s competitive abilities. 


e Project selection models can generally be classified as either 
numeric or nonnumeric; numeric models are further 
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subdivided into profitability, scoring, window-of-opportunity 
analysis, and discovery-driven planning categories. 


e Nonnumeric models include (1) the sacred cow; (2) the 


operating necessity; (3) the competitive necessity; and 
(4) comparative benefit. 


e The weighted factor scoring model is the most flexible of 


the models since it can include monetary, numeric, and 
nonnumeric factors. 


Glossary 


Delphi A formalized method for trans- 
forming the opinions of a group of individ- 
uals into quantitative measures that can be 
aggregated to use in decision making. 


Governance Designing the entities and 
roles involved in initiating, planning, exe- 
cuting, and routinizing projects. 

Maturity The sophistication and experi- 
ence of an organization in managing mul- 
tiple projects. 

Model A way of looking at reality, usually 
for the purpose of abstracting and simplifying 


it, to make it understandable in a particu- 
lar context. 


Organizational project management The 
systematic management of projects, pro- 
grams, and portfolios to achieve the strate- 
gic goals of an organization. 


Portfolio A group or set of projects with 
varying characteristics. 


Proforma Projected or anticipated, usu- 
ally applied to financial data such as bal- 
ance sheets and income statements. 


Project portfolio management A pro- 
cedure for selecting, implementing, and 
reviewing projects that will help an organi- 
zation achieve its strategic goals. 


Simulation A technique for emulating a 
process, usually conducted a considerable 
number of times to understand the process 
better and measure its outcomes under dif- 
ferent policies. 


Questions 


Material Review Questions 


1. Who in the governance structure has the longest serving role? 


2. Contrast the competitive necessity model with the operat- 
ing necessity model. What are the advantages and disadvan- 
tages of each? 

3. What is a sacred cow? Give some examples. 

4. Give an example of a Q-Sort process for project selection. 

5. What are some of the limitations of project selection models? 

6. Contrast the real options selection approach with profitabil- 
ity models. 

7. How does the discounted cash flow method answer some of 
the criticisms of the payback period method? 

8. What are some advantages and disadvantages of the profit/ 
profitability numeric models? 

9. What is the desired result of applying project portfolio man- 
agement? What do firms usually find happens? 

10. Describe the discovery-driven planning approach. 
11. Describe the project portfolio management process. 


12. 


13. 


Describe the various phases of governance for strategic 
projects and their purpose. 


Why do many researchers consider the first governance 
phase to be the most important? 


Class Discussion Questions 


14. 


15. 


16. 


17. 


18. 


19. 


Which of the many purposes of project portfolio manage- 
ment are most important to a firm with a low project man- 
agement maturity? Which to a firm with high maturity? 


On what basis does the real options model select projects? 


What is the difference between profitability and scoring 
models? Describe a model that could fit both categories. 


Contrast the window-of-opportunity approach with discovery- 
driven planning. 


Discuss how the following project selection models are 
used in real-world applications. (a) Capital investment with 
discounted cash flow. (b) Simulation models. 


Why do you think managers underutilize project selec- 
tion models? 


20 


21. 


22. 


. Would uncertainty models be classified as profitability 


models, scoring models, or some other type of model? 


Recent research on strategic projects has found that “scope” 
is much more important than either time or cost. Why do 
you think so? 


Are there certain types of projects that are better suited for 
nonnumeric selection methods as opposed to numeric ones? 


Exercises 


1. 


Two new Internet site projects are proposed to a young 
start-up company. Project A will cost $250,000 to implement 
and is expected to have annual net cash flows of $75,000. 
Project B will cost $150,000 to implement and should gen- 
erate annual net cash flows of $52,000. The company is very 
concerned about their cash flow. Using the payback period, 
which project is better, from a cash flow standpoint? 


. Sean, a new graduate at a telecommunications firm, faces 


the following problem his first day at the firm: What is the 
average rate of return for a project that costs $200,000 to 
implement and has an average annual profit of $30,000? 


. A 4-year financial project has net cash flows of $20,000; 


$25,000; $30,000; and $50,000 in the next 4 years. It will 
cost $75,000 to implement the project. If the required rate 
of return is 0.2, conduct a discounted cash flow calculation 
to determine the NPV. 


. What would happen to the NPV of the above project if the 


inflation rate was expected to be 4 percent in each of the 
next 4 years? 


. A 4-year financial project has estimates of net cash flows 


shown in the following table: 


Year Net Cash Flow 


1 $20,000 
2D 25,000 
3 30,000 
4 35,000 


It will cost $65,000 to implement the project, all of which 
must be invested at the beginning of the project. After the 
fourth year, the project will have no residual value. 


Using the most likely estimates of cash flows, conduct a dis- 
counted cash flow calculation assuming a 20 percent hurdle 
rate with no inflation. (You may use either an Excel® or a 
paper-and-pencil calculation.) What is the discounted profit- 
ability index of the project? 


. Use a weighted score model to choose between three pro- 


jects (A, B, C) for updating an important internal process. 
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23. What important comparisons does the aggregate project 


plan in Figure 2.3 allow? 


24. Which roles in the governance structure do you think are the 


most well-defined and the least well-defined? 


25. If sustainability focuses on long-run profitability, why is it 


classified as a “nonnumeric” model? 


The relative weights for each criterion are shown in the fol- 
lowing table as are the scores for each project on each cri- 
terion. A score of 1 represents unfavorable, 2 satisfactory, 
and 3 favorable. 


Project 

Criterion 

Cost 20 1 2 3 
Risk 20 2) 3 1 
Opportunity 10 2 1 3 
Profitability 10 3 3 2 
Sustainability 10 D; 1 1 
Safety Ds 1 2; 3 
Competitiveness 10 Dp; 2 Dp; 


7. Develop a spreadsheet for Exercise 6 


a. What would your recommendation be if the weight for 
the safety went down to 10 and the weight of profitability 
went up to 25? 


b. Suppose instead that method A received a score of 3 for 
safety. Would your recommendation change under these 
circumstances? 


c. The vice president of finance has looked at your original 
scoring model and feels that tax considerations should be 
included in the model with a weight of 15. In addition, the 
VP has scored the methods on tax considerations as follows: 
method A received a score of 3, method B received a score 
of 2, and method C received a score of 1. How would this 
additional information affect your recommendation? 


8. Nina is trying to decide in which of four shopping cen- 


ters to locate her new boutique. Some locations attract 
a higher class of clientele than others, some are in an 
indoor mall, some have a much greater customer traffic 
volume than others, and, of course, rent varies consider- 
ably from one location to another. Because of the nature 
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of her store, she has decided that the class of clientele is 
the most important consideration, the higher the better. 
Following this, however, she must pay attention to her 
expenses and rent is a major item, probably 90 percent as 
important as clientele. An indoor, temperature-controlled 
mall is a big help, however, for stores such as hers where 
70 percent of sales are from passersby slowly stroll- 
ing and window shopping. Thus, she rates this as about 
95 percent as important as rent. Last, a higher traffic volume 
of shoppers means more potential sales; she thus rates this 
factor as 80 percent as important as rent. 
As an aid in visualizing her location alternatives, she 
has constructed the following table. A “good” is scored as 3, 
“fair” as 2, and “poor” as 1. Use a weighted score model to 
help Nina come to a decision. 


Incidents For Discussion 


Portillo, Inc. 


Portillo, Inc. is a manufacturer of small household appliances 
and cooking utensils. Working with Johanna Portillo, the CEO 
of the firm, her executive team has developed a scoring model to 
analyze and select new items to be added to the product line. The 
model is also used to select old items to be dropped from the line. 
It employs both objective and subjective estimates of scores for 
the financial and nonfinancial elements that make up the model. 
The model is used by a Drop/Add Committee she appointed. 

Ms. Portillo is pleased with the construct of the model and 
feels that it includes all of the factors relevant to the drop/add 
decision. She is also comfortable with the factor weights devel- 
oped by her executives. 

Following a review of the past year’s meetings of the Drop/ 
Add Committee, Ms. Portillo discovered that several managers 
made significant errors when estimating costs and benefits of 
many projects. After a careful study of the estimates, she noticed 
that the sponsors of a product seemed to overestimate its benefits 
and underestimate its costs. It also appeared that other manag- 
ers might be underestimating benefits and overestimating costs. 

She was not sure about her suspicions and wondered how 
to find out if her notions were correct. Even if they were correct, 
she wondered what to do about it. 


Questions 


How can Ms. Portillo find out if her suspicions are correct? 
What are her options if her idea is supported? 


Location 


1 2 3 4 


Class of clientele Fair Good Poor Good 
Rent Good Fair Poor Good 
Indoor mall Good Poor Good Poor 
Traffic volume Good Fair Good Poor 


9. Referring to Exercise 8, develop a spreadsheet to help Nina 
select a location for her boutique. Suppose Nina is able to 
negotiate a lower rent at location 3 and thus raise its ranking 
to “good.” How does this affect the overall rankings of the 
four locations? 


L &M Power 


In the next 2 years, a large municipal gas company must begin 
constructing new gas storage facilities to accommodate the Fed- 
eral Energy Regulatory Commission’s Order 636 deregulating 
the gas industry. The vice-president in charge of the new project 
believes there are two options. One option is an underground 
deep storage facility (UDSF) and the other is a liquefied natural 
gas facility (LNGF). The vice-president has developed a pro- 
ject selection model and will use it in presenting the project to 
the president. For the models, she has gathered the following 
information: 
Initial Operating Expected Salvage 
Cost/Cu. Ft. Life Value 


$0.004 20 years 10% 
0.002 15 5 


Cost 
UDSF_ $10,000,000 


LNGF = 25,000,000 


Since the vice-president’s background is in finance, she 
believes the best model to use is a financial one, NPV analysis. 


Questions 
Would you use this model? Why or why not? 


Continuing Integrative Class Project 


The task for the class here is to select an appropriate project for 
the course, if one wasn’t already selected. Consideration should 
be given to the fixed end-of-term deadline, the limited monetary 


but large personnel resources available, the irrelevance of finan- 
cial returns, and the availability of contacts and good project 
possibilities outside the classroom. As indicated in Chapter 1, 


there are often many excellent projects on a college campus, 
such as in the residence halls, the library, the cafeteria, the medi- 
cal care office, and so on. When evaluating these situations for 
potential projects, consider factors such as whether the class 
has a good inside contact to sponsor the project, whether data 
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The following case concerns a European firm trying to choose between almost a dozen capital 
investment projects being championed by different executives in the firm. However, there are many 
more projects available for funding than there are funds available to implement them, so the set must 
be narrowed down to the most valuable and important to the firm. Financial, strategic, and other data 
are given concerning the projects in order to facilitate the analysis needed to make a final investment 


recommendation to the Board of Directors. 


Case 


Pan-Europa Foods S.A* _ C. Opitz and R. F. Bruner 


It was early January, and the senior-management committee 
of Pan-Europa Foods was to meet to draw up the firm’s capital 
budget for the new year. Up for consideration were 11 major 
projects that totaled over €208 million (euros). Unfortunately, 
the board of directors had imposed a spending limit of only 
€80 million; even so, investment at that rate would repre- 
sent a major increase in the firm’s asset base of €656 million. 
Thus the challenge for the senior managers of Pan-Europa 
was to allocate funds among a range of compelling projects: 
new-product introduction, acquisition, market expansion, 
efficiency improvements, preventive maintenance, safety, and 
pollution control. 


The Company 


Pan-Europa Foods, headquartered in Brussels, Belgium, was 
a multinational producer of high-quality ice cream, yogurt, 
bottled water, and fruit juices. Its products were sold throughout 
Scandinavia, Britain, Belgium, the Netherlands, Luxembourg, 
western Germany, and northern France (see Exhibit 1 for a map 
of the company’s marketing region). 

The company was founded in 1924 by Theo Verdin, a 
Belgian farmer, as an offshoot of his dairy business. Through 
keen attention to product development, and shrewd marketing, 
the business grew steadily over the years. The company went 
public in 1979 and by 1993 was listed for trading on the London, 
Frankfurt, and Brussels exchanges. Last year Pan-Europa had 
sales of almost €1.1 billion. 

Ice cream accounted for 60 percent of the company’s reve- 
nues; yogurt, which was introduced in 1982, contributed about 
20 percent. The remaining 20 percent of sales was divided 
equally between bottled water and fruit juices. Pan-Europa’s 
flagship brand name was “Rolly,” which was represented by a 
fat, dancing bear in farmers’ clothing. Ice cream, the company’s 
leading product, had a loyal base of customers who sought out 
its high butterfat content, large chunks of chocolate, fruit, nuts, 
and wide range of original flavors. 

Recently, Pan-Europa sales had been static (see Exhibit 2), 
which management attributed to low population growth in 
northern Europe and market saturation in some areas. Outside 
observers, however, faulted recent failures in new-product intro- 
ductions. Most members of management wanted to expand the 
*Reprinted with permission. Copyright Darden Graduate Business 
School Foundation, Charlottesville, Virginia. 


company’s market presence and introduce more new products 
to boost sales. These managers hoped that increased market 
presence and sales would improve the company’s market value. 
Pan-Europa’s stock was currently at eight times earnings, just 
below book value. This price/earnings ratio was below the 
trading multiples of comparable companies, but it gave little 
value to the company’s brands. 


Resource Allocation 


The capital budget at Pan-Europa was prepared annually by 
a committee of senior managers who then presented it for 
approval by the board of directors. The committee consisted 
of five managing directors, the président directeur-général 
(PDG), and the finance director. Typically, the PDG solic- 
ited investment proposals from the managing directors. The 
proposals included a brief project description, a financial 
analysis, and a discussion of strategic or other qualitative con- 
siderations. 

As a matter of policy, investment proposals at Pan-Europa 
were subjected to two financial tests, payback and internal rate 
of return (IRR). The tests, or hurdles, had been established by 
the management committee and varied according to the type 
of project: 


Maximum 
Minimum Acceptable 
Acceptable Payback 
Type of Project IRR Years 
1. New product or new 12% 6 years 
markets 
2. Product or market 10% 5 years 
extension 
3. Efficiency improvements 8% 4 years 
4. Safety or environmental No test No test 


The most recent estimated weighted-average cost of capital 
(WACC) for Pan-Europa was 10.5 percent. In describing the 
capital-budgeting process, the finance director, Trudi Lauf, said, 
“We use the sliding scale of IRR tests as a way of recognizing 
differences in risk among the various types of projects. Where 
the company takes more risk, we should earn more return. The 
payback test signals that we are not prepared to wait for long to 
achieve that return.” 
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VA 


> il:juee Pan-Europa Foods S. A. Nations Where Pan-Europa Competed 
Note: The shaded area in this map reveals the principal distribution region of Pan-Europa’s products. Important 
facilities are indicated by the following figures: 


1. Headquarters, Brussels, Belgium 6. Plant, Copenhagen, Denmark 

2. Plant, Antwerp, Belgium 7. Plant, Svald, Sweden 

3. Plant, Strasbourg, France 8. Plant, Nelly-on-Mersey, England 
4. Plant, Nuremberg, Germany 9. Plant, Caen, France 

5. Plant, Hamburg, Germany 10. Plant, Melun, France 


: : Ownership and the Sentiment of Creditors and Investors 
Pan-Europa’s 12-member board of directors included three 
members of the Verdin family, four members of management, 
and five outside directors who were prominent managers or 
public figures in northern Europe. Members of the Verdin fam- 

Gross sales 1,076 1,072 1,074 ily combined owned 20 percent of Pan-Europa’s shares out- 
nn sa | a standing, and company executives owned 10 percent of the 
88 shares. Venus Asset Management, a mutual-fund management 

Earnings per share 0.75 0.72 0.54 company in London, held 12 percent. Banque du Bruges et 
nen des Pays Bas held 9 percent and had one representative on 


Previous Last This 
Year Year Year 


2 eee eee ae the board of directors. The remaining 49 percent of the firm’s 
Total assets 477 580 656 shares were widely held. The firm’s shares traded in London, 
Shareholders’ equity 182 206 235 ae en a 
ibook value) t a debt-to-equity ratio of 125 percent, Pan-Europa was 

2 leveraged much more highly than its peers in the European 
Shareholders’ equity 453 400 229 consumer-foods industry. Management had relied on debt 
(market value) financing significantly in the past few years to sustain the firm’s 

capital spending and dividends during a period of price wars 

Summary of Financial Results (all values in initiated by Pan-Europa. Now, with the price wars finished, Pan- 


€ millions except per-share amounts) Europa’s bankers (led by Banque du Bruges) strongly urged an 
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aggressive program of debt reduction. In any event, they were to four alternative capital budgets. The various executives were 


well known to each other: 


not prepared to finance increases in leverage beyond the current 
level. The president of Banque du Bruges had remarked at a 
recent board meeting, 


Restoring some strength to the right-hand 

side of the balance sheet should now be a first 
priority. Any expansion of assets should be 
financed from the cash flow after debt amor- 
tization until the debt ratio returns to a more 
prudent level. If there are crucial investments 
that cannot be funded this way, then we should 
cut the dividend! 


At a price-to-earnings ratio of eight times, shares of 
Pan-Europa common stock were priced below the average mul- 
tiples of peer companies and the average multiples of all com- 
panies on the exchanges where Pan-Europa was traded. This 
was attributable to the recent price wars, which had suppressed 
the company’s profitability, and to the well-known recent fail- 
ure of the company to seize significant market share with a 
new product line of flavored mineral water. Since last year, all 
of the major securities houses had been issuing “sell” recom- 
mendations to investors in Pan-Europa shares. Venus Asset 
Management in London had quietly accumulated shares dur- 
ing this period, however, in the expectation of a turnaround 
in the firm’s performance. At the most recent board meeting, 
the senior managing director of Venus gave a presentation in 
which he said, 


Cutting the dividend is unthinkable, as it would 
signal a lack of faith in your own future. Selling 
new shares of stock at this depressed price level 
is also unthinkable, as it would impose unac- 
ceptable dilution on your current shareholders. 
Your equity investors expect an improvement 

in performance. If that improvement is not 
forthcoming, or worse, if investors’ hopes are 
dashed, your shares might fall into the hands 

of raiders like Carlo de Benedetti or the Flick 
brothers.! 


At the conclusion of the most recent meeting of the direc- 
tors, the board voted unanimously to limit capital spending in 
the next year to €80 million. 


Members of the Senior Management Committee 


The capital budget would be prepared by seven senior managers 
of Pan-Europa. For consideration, each project had to be spon- 
sored by one of the managers present. Usually the decision pro- 
cess included a period of discussion followed by a vote on two 


'De Benedetti of Milan and the Flick brothers of Munich were leaders 
of prominent hostile-takeover attempts in recent years. 


Wilhelmina Verdin (Belgian), PDG, age 57. Granddaughter 
of the founder and spokesperson on the board of directors 
for the Verdin family’s interests. Worked for the company 
her entire career, with significant experience in brand 
management. Elected “European Marketer of the Year” in 
1982 for successfully introducing low-fat yogurt and ice 
cream, the first major roll-out of this type of product. Eager 
to position the company for long-term growth but cautious 
in the wake of recent difficulties. 


Trudi Lauf (Swiss), finance director, age 51. Hired from 
Nestlé to modernize financial controls and systems. Had 
been a vocal proponent of reducing leverage on the balance 
sheet. Also had voiced the concerns and frustrations of 
stockholders. 


Heinz Klink (German), managing director for Distribu- 
tion, age 49. Oversaw the transportation, warehousing, and 
order-fulfillment activities in the company. Spoilage, trans- 
port costs, stock-outs, and control systems were perennial 
challenges. 


Maarten Leyden (Dutch), managing director for Produc- 
tion and Purchasing, age 59. Managed production oper- 
ations at the company’s 14 plants. Engineer by training. 
Tough negotiator, especially with unions and suppliers. 
A fanatic about production-cost control. Had voiced 
doubts about the sincerity of creditors’ and investors’ com- 
mitment to the firm. 


Marco Ponti (Italian), managing director for Sales, age 
45. Oversaw the field sales force of 250 representatives 
and planned changes in geographical sales coverage. The 
most vocal proponent of rapid expansion on the senior- 
management committee. Saw several opportunities for 
ways to improve geographical positioning. Hired from Uni- 
lever to revitalize the sales organization, which he success- 
fully accomplished. 


Fabienne Morin (French), managing director for Marketing, 
age 41. Responsible for marketing research, new-product 
development, advertising, and, in general, brand man- 
agement. The primary advocate of the recent price war, 
which, although financially difficult, realized solid gains 
in market share. Perceived a “window of opportunity” 
for product and market expansion and tended to support 
growth-oriented projects. 

Nigel Humbolt (British), managing director for Strate- 
gic Planning, age 47. Hired 2 years previously from a 
well-known consulting firm to set up a strategic- planning 
staff for Pan-Europa. Known for asking -difficult and chal- 
lenging questions about Pan-Europa’s core business, its 
maturity, and profitability. Supported initiatives aimed at 
growth and market share. Had presented the most aggres- 
sive proposals in 1992, none of which were accepted. 
Becoming frustrated with what he perceived to be his lack 
of influence in the organization. 
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Expenditure Proposals 


forthcoming meeting would entertain the following pro- 


posals (see summary table also): 


1. 


Replacement and expansion of the truck fleet Heinz 
Klink proposed to purchase 100 new refrigerated tractor 
trailer trucks, 50 this year and another 50 next year. By doing 
so, the company could sell 60 old, fully depreciated trucks 
over the two years for a total of €1.2 million. The purchase 
would expand the fleet by 40 trucks within two years. Each 
of the new trailers would be larger than the old trailers and 
afford a 15 percent increase in cubic meters of goods hauled 
on each trip. The new tractors would also be more fuel and 
maintenance efficient. The increase in number of trucks 
would permit more flexible scheduling and more efficient 


Project 


Oo }/alrnl_ nt n 


11. 


. Replacement and expansion of the truck fleet 
. A new plant 
. Expansion of a plant 


. Development and introduction of new artificially sweetened 


yogurt and ice cream 


. Plant automation and conveyor systems 

. Effluent water treatment at four plants 
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routing and servicing of the fleet than at present and would 
cut delivery times and, therefore, possibly inventories. It 
would also allow more frequent deliveries to the company’s 
major markets, which would reduce the loss of sales caused 
by stock-outs. Finally, expanding the fleet would support 
geographical expansion over the long term. As shown in 
Exhibit 3, the total net investment in trucks of €20 million 
and the increase in working capital to support added main- 
tenance, fuel, payroll, and inventories of €2 million was 
expected to yield total cost savings and added sales poten- 
tial of €7.7 million over the next seven years. The resulting 
IRR was estimated to be 7.8 percent, marginally below the 
minimum 8 percent required return on efficiency projects. 
Some of the managers wondered if this project would be 
more properly classified as “efficiency” than “expansion.” 


Expenditure 
(€ millions) Sponsoring Manager 
2p Klink, Distribution 
30 Leyden, Production 
10 Leyden, Production 
15 Morin, Marketing 
14 Leyden, Production 
4 Leyden, Production 
20 Ponti, Sales 
20 Ponti, Sales 
18 Morin, Marketing 
15 Klink, Distribution 
40 Humbolt, Strategic Planning 


2. 


A new plant Maarten Leyden noted that Pan-Europa’s 
yogurt and ice-cream sales in the southeastern region of the 
company’s market were about to exceed the capacity of its 
Melun, France, manufacturing and packaging plant. At pre- 
sent, some of the demand was being met by shipments from 
the company’s newest, most efficient facility, located in 
Strasbourg, France. Shipping costs over that distance were 
high, however, and some sales were undoubtedly being 
lost when the marketing effort could not be supported by 
delivery. Leyden proposed that a new manufacturing and 
packaging plant be built in Dijon, France, just at the current 
southern edge of Pan-Europa’s marketing region, to take 
the burden off the Melun and Strasbourg plants. 


The cost of this plant would be €25 million and would 
entail €5 million for working capital. The €14 million worth 
of equipment would be amortized over seven years, and the 
plant over ten years. Through an increase in sales and 
depreciation, and the decrease in delivery costs, the plant 


. Expansion of a plant 


was expected to yield after-tax cash flows totaling €23.75 
million and an IRR of 11.3 percent over the next ten years. 
This project would be classified as a market extension. 


In addition to the need for greater 
production capacity in Pan-Europa’s southeastern region, its 
Nuremberg, Germany, plant had reached full capacity. This 
situation made the scheduling of routine equipment mainte- 
nance difficult, which, in turn, created production schedul- 
ing and deadline problems. This plant was one of two highly 
automated facilities that produced Pan-Europa’s entire line of 
bottled water, mineral water, and fruit juices. The Nuremberg 
plant supplied central and western Europe. (The other plant, 
near Copenhagen, Denmark, supplied Pan-Europa’s northern 
European markets.) 


The Nuremberg plant’s capacity could be expanded by 
20 percent for €10 million. The equipment (€7 million) 
would be depreciated over seven years, and the plant over 
ten years. The increased capacity was expected to result in 
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Expand Automation Eastward Southward Inventory- Strategic 
Truck Flect New Expanded Artificial and Conveyer Expansion Expansion Snack Control Acquisition 
Project (note 3) Plant Plant Sweetener Systems (note 5) (note 5) Foods System (note 6) 
Investment 
Property 20.00 25.00 10.00 15.00 14.00 15.00 15.00 30.00 
Working Capital 2.00 5.00 20.00 20.00 3.00 10.00 
Year EXPECTED FREE CASH FLOWS (note 4) 
(11.40) (30.00) (10.00) (5.00) (14.00) (20.00) (20.00) (18.00) (12.00) (15.00) 
1 (7.90) 2.00 es) (5.00) 215 3.50 3.00 3.00 5.50 (20.00) 
2 3.00 5.00 1.50 (5.00) OTB 4.00 3.50 4.00 5.50 5.00 
3 3.50 5.50 5 3.00 2.75 4.50 4.00 4.50 5.00 9.00 
4 4.00 6.00 2.00 3.00 275 5.00 4.50 5.00 11.00 
5 4.50 6.25 2.25 4.00 275 5.50 5.00 5.00 13.00 
6 5.00 6.50 2.50 4.50 279 6.00 5.50 5.00 15.00 
ah 7.00 6.75 1.50 5.00 275 6.50 6.00 5.00 17.00 
8 5.00 1.50 5.50 7.00 6.50 5.00 19.00 
9 3.25 1.50 6.00 7.50 7.00 5.00 21.00 
10 5.50 1.50 6.50 8.00 7.50 5.00 59.00 
Undiscounted Sum 7.70 23,75 P25 22.50 S25) 37.50 32.50 28.50 4.00 134.00 
Payback (years) 6 6 6 a) 6 5 6 5 3 a 
Maximum Payback Accepted 4 5 5 6 4 6 6 6 4 6 
IRR 7.8% 11.3% 11.2% 17.3% 8.7% 21.4% 18.8% 20.5% 16.2% 28.7% 
Minimum Accepted ROR 8.0% 10.0% 10.0% 12.0% 8.0% 12.0% 12.0% 12.0% 8.0% 12.0% 
Spread 0.2% 1.3% 1.2% 5.3% 0.7% 9.4% 6.8% 8.5% 8.2% 16.7% 
NPV at Corp. WACC (10.5%) — 192 0.99 0.28 3:21) —0.87 11.99 9.00 8.95 1.16 47.97 
NPV at Minimum ROR —0.13 1.87 0.55 3.88 0.32 9.90 7.08 7.31 1.78 41.43 
Equivalent Annuity* —0.02 0.30 0.09 0.69 0.06 ees 125 1.29 0.69 33) 


'The effluent treatment program is not included in this exhibit. 

?The equivalent annuity of a project is that level annual payment over 10 years that yields a net present value equal to the NPV at the minimum required rate of return for that project. Annuity corrects for differences in 
duration among various projects. For instance, project 5 lasts only 7 years and has an NPV of 0.32 million; a 10-year stream of annual cash flows of 0.05 million, discounted at 8.0 percent (the required rate of return) also 
yields an NPV of 0.32 million. In ranking projects on the basis of equivalent annuity, bigger annuities create more investor wealth than smaller annuities. 

*This reflects €11 million spent both initially and at the end of year 1. 

*Free cash flow = incremental profit or cost savings after taxes + depreciation — investment in fixed assets and working capital. 

‘Franchisees would gradually take over the burden of carrying receivables and inventory. 

*€15 million would be spent in the first year, 20 million in the second, and 5 million in the third. 


Free Cash Flows and Analysis of Proposed Projects! (all values in € millions) 
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additional production of up to €1.5 million per year, yield- 
ing an IRR of 11.2 percent. This project would be classified 
as a market extension. 


. Development and introduction of new artificially sweet- 
ened yogurt and ice cream Fabienne Morin noted that 
recent developments in the synthesis of artificial sweet- 
eners were showing promise of significant cost savings to 
food and beverage producers as well as stimulating growing 
demand for low-calorie products. The challenge was to 
create the right flavor to complement or enhance the other 
ingredients. For ice-cream manufacturers, the difficulty lay 
in creating a balance that would result in the same flavor 
as was obtained when using natural sweeteners; artificial 
sweeteners might, of course, create a superior taste. 


€15 million would be needed to commercialize a yogurt line 
that had received promising results in laboratory tests. This 
cost included acquiring specialized production facilities, 
working capital, and the cost of the initial product introduc- 
tion. The overall IRR was estimated to be 17.3 percent. 


Morin stressed that the proposal, although highly uncertain 
in terms of actual results, could be viewed as a means of 
protecting present market share, because other high-quality 
ice-cream producers carrying out the same research might 
introduce these products; if the Rolly brand did not carry an 
artificially sweetened line and its competitors did, the Rolly 
brand might suffer. Morin also noted the parallels between 
innovating with artificial sweeteners and the company’s past 
success in introducing low-fat products. This project would 
be classed in the new-product category of investments. 


. Plant automation and conveyor systems Maarten 
Leyden also requested €14 million to increase automation 
of the production lines at six of the company’s older plants. 
The result would be improved throughput speed and reduced 
accidents, spillage, and production tie-ups. The last two 
plants the company had built included conveyer systems that 
eliminated the need for any heavy lifting by employees. The 
systems reduced the chance of injury to employees; at the 
six older plants, the company had sustained an average of 
75 missed worker-days per year per plant in the last 2 years 
because of muscle injuries sustained in heavy lifting. At 
an average hourly wage of €14.00 per hour, over €150,000 
per year was thus lost, and the possibility always existed of 
more serious injuries and lawsuits. Overall cost savings and 
depreciation totaling €2.75 million per year for the project 
were expected to yield an IRR of 8.7 percent. This project 
would be classed in the efficiency category. 


. Effluent water treatment at four plants Pan-Europa 
preprocessed a variety of fresh fruits at its Melun and Stras- 
bourg plants. One of the first stages of processing involved 
cleaning the fruit to remove dirt and pesticides. The dirty 
water was simply sent down the drain and into the Seine 
or Rhine rivers. Recent European Community directives 
called for any waste water containing even slight traces of 
poisonous chemicals to be treated at the sources and gave 
companies 4 years to comply. As an environmentally ori- 
ented project, this proposal fell outside the normal financial 
tests of project attractiveness. Leyden noted, however, that 
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the water-treatment equipment could be purchased today for 
€4 million; he speculated that the same equipment would 
cost €10 million in 4 years when immediate conversion 
became mandatory. In the intervening time, the company 
would run the risks that European Community regulators 
would shorten the compliance time or that the company’s 
pollution record would become public and impair the image 
of the company in the eyes of the consumer. This project 
would be classed in the environmental category. 


. and 8. Market expansions eastward and southward 


Marco Ponti recommended that the company expand its 
market eastward to include eastern Germany, Poland, 
Czechoslovakia, and Austria and/or southward to include 
southern France, Switzerland, Italy, and Spain. He believed 
the time was right to expand sales of ice cream, and per- 
haps yogurt, geographically. In theory, the company could 
sustain expansions in both directions simultaneously, but 
practically, Ponti doubted that the sales and distribution 
organizations could sustain both expansions at once. 


Each alternative geographical expansion had its benefits 
and risks. If the company expanded eastward, it could reach 
a large population with a great appetite for frozen dairy 
products, but it would also face more competition from 
local and regional ice-cream manufacturers. Moreover, 
consumers in eastern Germany, Poland, and Czechoslovakia 
did not have the purchasing power that consumers did to the 
south. The eastward expansion would have to be supplied 
from plants in Nuremberg, Strasbourg, and Hamburg. 


Looking southward, the tables were turned: more pur- 
chasing power and less competition but also a smaller 
consumer appetite for ice cream and yogurt. A southward 
expansion would require building consumer demand for 
premium-quality yogurt and ice cream. If neither of the 
plant proposals (i.e., proposals 2 and 3) were accepted, then 
the southward expansion would need to be supplied from 
plants in Melun, Strasbourg, and Rouen. 


The initial cost of either proposal was €20 million of 
working capital. The bulk of this project’s costs was 
expected to involve the financing of distributorships, but 
over the 10-year forecast period, the distributors would 
gradually take over the burden of carrying receivables and 
inventory. Both expansion proposals assumed the rental of 
suitable warehouse and distribution facilities. The after-tax 
cash flows were expected to total €37.5 million for east- 
ward expansion and €32.5 million for southward expansion. 


Marco Ponti pointed out that eastward expansion meant a 
higher possible IRR but that moving southward was a less 
risky proposition. The projected IRRs were 21.4 percent 
and 18.8 percent for eastern and southern expansion, 
respectively. These projects would be classed in the new 
market category. 


. Development and roll-out of snack foods Fabienne 


Morin suggested that the company use the excess capacity 
at its Antwerp spice and nut-processing facility to produce a 
line of dried fruits to be test-marketed in Belgium, Britain, 
and the Netherlands. She noted the strength of the Rolly 
brand in those countries and the success of other food and 
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beverage companies that had expanded into snack food 
production. She argued that Pan-Europa’s reputation for 
wholesome, quality products would be enhanced by a line 
of dried fruits and that name association with the new prod- 
uct would probably even lead to increased sales of the com- 
pany’s other products among health-conscious consumers. 


Equipment and working-capital investments were expected 
to total €15 million and €3 million, respectively, for this 
project. The equipment would be depreciated over 7 years. 
Assuming the test market was successful, cash flows from 
the project would be able to support further plant expan- 
sions in other strategic locations. The IRR was expected to 
be 20.5 percent, well above the required return of 12 per- 
cent for new-product projects. 


Networked, computer-based inventory-control system for 
warehouses and field representatives. Heinz klink had 
pressed for three years unsuccessfully for a state-of-the-art 
computer-based inventory-control system that would link 
field sales representatives, distributors, drivers, warehouses, 
and even possibly retailers. The benefits of such a sys- 
tem would be shortening delays in ordering and order 


Case 67 


The proposal was expensive: €15 million to buy the com- 
pany and €25 million to renovate the company’s facilities 
completely while simultaneously expanding distribution to 
new geographical markets. The expected returns were 
high: after-tax cash flows were projected to be €134 mil- 
lion, yielding an IRR of 28.7 percent. This project would be 
classed in the new-product category of proposals. 


Conclusion 


Each member of the management committee was expected to 
come to the meeting prepared to present and defend a proposal 
for the allocation of Pan-Europa’s capital budget of €80 million. 
Exhibit 3 summarizes the various projects in terms of their free 
cash flows and the investment—performance criteria. 


Questions 


1. 


Strategically, what must Pan-Europa do to keep from becom- 
ing the victim of a hostile takeover? What rows/categories in 
Exhibit 2 will thus become critically important this coming 
year? What should Pan-Europa do now that they have won 
the price war? Who should lead the way for Pan-Europa? 


processing, better control of inventory, reduction of spoil- 2. Using NPV, conduct a straight financial analysis of the 
age, and faster recognition of changes in demand at the investment alternatives and rank the projects. Which NPV 
customer level. Klink was reluctant to quantify these ben- of the three should be used? Why? Suggest a way to evaluate 
efits, because they could range between modest and quite the effluent project. 
large amounts. This year, for the first time, he presented a = 3, What aspects of the projects might invalidate the ranking you 
cash-flow forecast, however, that reflected an initial outlay just derived? How should we correct for each investment’s 
of €12 million for the system, followed by €3 million in time value of money, unequal lifetimes, riskiness, and size? 
the next year for ancillary equipment. The inflows reflected 4. Ressnsider the proicow tnitetins of 
depreciation tax shields, tax credits, cost reductions in ; . ; : 
ware-housing, and reduced inventory. He forecasted these e are any “must do” projects of the nonnumeric type? 
benefits to last for only three years. Even so, the project’s e what elements of the projects might imply greater or 
IRR was estimated to be 16.2 percent. This project would lesser riskiness? 
be classed in the efficiency category of proposals. e might there be any synergies or conflicts between 
11. Acquisition of a leading schnapps brand and associated the projects? 
facilities ; Nigel Humbolt had advocated making diversify- e do any of the projects have nonquantitative benefits or 
ME Be QUaSItLOnS In, WH effort fo Move beyond the company’s costs that should be considered in an evaluation? 
aan oe poten DUE dane Seaway abexDloled me 5. Considering all the above, what screens/factors might you 
company’s skills in brand management. He had explored six a - 
: : So ae . suggest to narrow down the set of most desirable projects? 
possible related industries, in the general field of consumer ane ; 
: : . What criteria would you use to evaluate the projects on these 
packaged goods, and determined that cordials and liqueurs ; : : 
- various factors? Do any of the projects fail to pass these 
offered unusual opportunities for real growth and, at the same : 
: : . : ee screens due to their extreme values on some of the factors? 
time, market protection through branding. He had identified _ . : ; ; 
four small producers of well-established brands of liqueurs 6. Divide the projects into the four project categories of 
as acquisition candidates. Following exploratory talks with derivative, platform, breakthrough, and R&D. Draw an 
each, he had determined that only one company could be aggregate project plan and array the projects on the chart, 
purchased in the near future, namely, the leading private 7. Based on all the above, which projects should the manage- 


European manufacturer of schnapps, located in Munich. 


ment committee recommend to the Board of Directors? 


The following reading describes the approach Hewlett-Packard uses to select and monitor its projects 
for relevance to the firm’s strategic goals. The article describes the behavioral aspects of the process 
as well as many of the technical tools, such as the aggregate project plan, the plan of record, and the 
software aids they employed. In addition, the authors give tips and identify pitfalls in the process so 
anyone else implementing their approach will know what problems to watch out for. 


*Exhibit 3 shows negative cash flows amounting to only €35 million. The difference between this amount and 
the €40 million requested is a positive operating cash flow of €5 million in year 1 expected from the normal 
course of business. 
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Reading 


From Experience: Linking Projects 
To Strategy* R.L. Englund and R. J. Graham 


Growth in organizations typically results from successful pro- 
jects that generate new products, services, or procedures. Man- 
agers are increasingly concerned about getting better results 
from the projects under way in their organizations and in getting 
better cross-organizational cooperation. One of the most vocal 
complaints of project managers is that projects appear almost 
randomly. The projects seem unlinked to a coherent strategy, and 
people are unaware of the total number and scope of projects. As 
a result, people feel they are working at cross-purposes, on too 
many unneeded projects, and on too many projects generally. 
Selecting projects for their strategic emphasis helps resolve such 
feelings and is a corner anchor in putting together the pieces of 
a puzzle that create an environment for successful projects [6]. 

This article covers a series of steps for linking projects to 
strategy. These steps constitute a process that can be applied 
to any endeavor. Included throughout are suggestions for action 
as well as guidelines to navigate many pitfalls along the path. 
Process tools help illustrate ways to prioritize projects. The 
lessons learned are from consulting with many firms over a 
long time period and from personal experiences in applying 
the lessons within Hewlett-Packard Company (HP), a $40 bil- 
lion plus company where two-thirds of its revenue derives from 
products introduced within the past 2 years. 


The Importance of Upper Management Teamwork 


Developing cooperation across an organization requires that 
upper managers take a systems approach to projects. That means 
they look at projects as a system of interrelated activities that 
combine to achieve a common goal. The common goal is to ful- 
fill the overall strategy of the organization. Usually all projects 
draw from one resource pool, so they interrelate as they share 
the same resources. Thus, the system of projects is itself a proj- 
ect, with the smaller projects being the activities that lead to the 
larger project (organizational) goal. 

Any lack of upper management teamwork reverberates 
throughout the organization. If upper managers do not model 
desired behaviors, there is little hope that the rest of the organi- 
zation can do it for them. Any lack of upper management coop- 
eration will surely be reflected in the behavior of project teams, 
and there is little chance that project managers alone can resolve 
the problems that arise. 

A council concept is one mechanism used at HP to 
establish a strategic direction for projects spanning organiza- 
tional boundaries. A council may be permanent or temporary, 
assembled to solve strategic issues. As a result, a council typ- 
ically will involve upper managers. Usually its role is to set 


*Reprinted from Journal of Product Innovation Management with per- 
mission. Copyright Elsevier Science Publishers. 
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directions, manage multiple projects or a set of projects, and 
aid in cross-organizational issue resolution. Several of these 
council-like activities become evident through the examples 
in this article. 

Employing a comprehensive and systematic approach illus- 
trates the vast and important influence of upper management 
teamwork on project success. Increasingly evident are com- 
panies who initiate portfolio selection committees. We suggest 
that organizations begin by developing councils to work with 
project managers and to implement strategy. These councils 
exercise leadership by articulating a vision, discussing it with the 
project managers, asking them their concerns about and needs 
for implementing the strategy, listening carefully to them, and 
showing them respect so they become engaged in the process. 
In this way, upper managers and project managers develop the 
joint vision that is so necessary for implementation of strategy. 


Process for Project Selection and Prioritization 


Once the upper management team is established, they can 
follow a process to select sets of projects that achieve organi- 
zational goals. They are then ideally positioned to implement 
consistent priorities across all departments. Figure 1 represents 
a mental model of a way to structure this process. Outputs from 
the four steps interrelate in a true systems approach. This model 
comes from experience in researching and applying a thorough 
approach to all the issues encountered in a complex organiza- 
tion. It is both simple in concept and complex in richness. The 
authors use the model both as an educational tool and to facili- 
tate management teams through the process. 


What the Organization Should Do and How to Know 
When You Are Doing It 


First, identify who is leading the process and who should be on 
the management team. More time spent here putting together 
a “mission impossible” team pays dividends later by getting 
up-front involvement of the people who will be affected by the 
decisions that will be made. Take care not to overlook any key- 
but-not-so-visible players who later may speak up and jeopar- 
dize the plan. This team may consist solely of upper managers or 
may include project managers, a general manager, and possibly a 
customer. Include representation of those who can best address 
the key opportunities and risks facing the organization. Ideally 
they control the resources and are empowered to make decisions 
on all projects. The leader needs to get explicit commitment 
from all these people to participate actively in the process and to 
use the resulting plan when making related decisions. Be aware 
that behavioral issues become super urgent. This process hits 
close to home and may have a severe impact on projects that 
people care personally about. Uncertainty and doubt are cre- 
ated if management does not tread carefully and pay attention 
to people concerns. 

The team begins by listing all projects proposed and under 
way in the organization. Many times this step is a revelation 
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The actual products in Figure 2 were introduced 


¢ Use 1. What * People : : : 

¢ Fully fund drones * Goals to the market over time in alphabetical order and 
* Communicate * Categories positioning shown. Although the figure represents 
¢ Update * Criteria 


4. Do it! 


¢ Prioritized list 


¢ List projects 


a retrospective view, it illustrates a successful strat- 
egy of sequencing projects and products. There is 
a balanced mix of breakthrough products, such as 
A, followed by enhancements, B through E, before 
moving on to new platforms, F through H, and even- 
tually developing a new architecture and product 
family with L. At the time, this strategy was impro- 


Rejects 


: ea ects 7 Selo al visational [1]; it now represents a learning opportu- 
* In-plan * Critical few nity for planning new portfolios. No one area of the 
Out-plan grid is overpopulated, and where large projects exist 


| FIGURE 1 | A systematic approach to selecting projects. 


in itself. A usual reaction is, “I didn’t realize we had so many 
projects going on.” The intent is to survey the field of work 
and begin the organizing effort, so avoid going into detailed 
discussion about specific projects at this point. 

The team clarifies or develops the goals expected from 
projects. Be careful not to get 